[Bug nptl/245] New: lowlevellock.h not installed

[Bug nptl/245] New: lowlevellock.h not installed

[egmont at uhulinux dot hu]

I compiled and installed the glibc version found in Fedora core 2 using nptl.

The installed stdio-lock.h #includes a lowlevellock.h.
This lowlevellock.h is present in glibc's source, but is not installed
(and is missing from the nptl-devel package of Fedora, too).

This causes at least gcc-2.95 compilation to fail.

I don't know if the bug is fixed in current CVS, but ChangeLog of the last
several months doesn't mention lowlevellock.

-- 
           Summary: lowlevellock.h not installed
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: drepper at redhat dot com
        ReportedBy: egmont at uhulinux dot hu
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=245

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/245] lowlevellock.h not installed

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2004-06-30 16:02 -------
Fix gcc.  This header is not for userlevel code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://sources.redhat.com/bugzilla/show_bug.cgi?id=245

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/245] lowlevellock.h not installed

[egmont at uhulinux dot hu]

------- Additional Comments From egmont at uhulinux dot hu  2004-06-30 16:23 -------
Then why is bits/stdio-lock.h installed at all? It is unusable this way,
since tries to include <lowlevellock.h>. At least if this include statement
was surrounded by some #ifdef, but it isn't.

So then stdio-lock.h shouldn't be installed either to provide more a consistent
set of header files. IMHO it doesn't make any sense to install a header file
which is totally unusable due to missing dependencies.

(Believe me, I'd silently started to patch my gcc2 if I saw glibc simply
changing but remaining consistent to itself.)


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://sources.redhat.com/bugzilla/show_bug.cgi?id=245

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/245] lowlevellock.h not installed

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-09-23 19:55 -------
Don't reopen.  If you don't like the answer, go somewhere else.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=245

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/245] lowlevellock.h not installed

[egmont at uhulinux dot hu]

------- Additional Comments From egmont at uhulinux dot hu  2005-09-25 14:31 -------
"If you don't like the answer..." -- Well, sure I'd like the answer, if I'd
received any. But you didn't give an answer at all. No, I'm not talking about
gcc, I really don't care about gcc at all. What I'm talking about is that
glibc installs "a.h" which unconditionally #includes "b.h", but in the mean
time glibc does not install "b.h". This is an inconsistant and hence I believe
buggy behavior from glibc. It installs an unusable header file. It should
either also install "b.h" or not install "a.h" or make "a.h" not include "b.h".
(Gcc just happened to be the piece of software which led me hit this bug.
Forget it. I'm not talking about gcc. Only glibc.)

If, as you say, b.h is not for userlevel code, then please change glibc not to
install a.h either since then that one is also not suitable for userlevel code.

But, okay, as you requested it, I don't reopen the bug and I absolutely don't
care if you fix it or not. There are so many more important glibc bugs open and
waiting to be resolved... This one is really not important, but still I can't
see why it's invalid.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=245

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/245] Wrong stdio-lock.h installed

[bero at arklinux dot org]

------- Additional Comments From bero at arklinux dot org  2006-04-27 23:46 -------
The problem is valid (you can't #include stdio-lock.h anywhere), but the 
suggested fix (which caused it to be marked as invalid) isn't.

Alternative fix that doesn't drag lowlevellock.h into the include dependency 
chain:
glibc's make install installs nptl/sysdeps/pthread/bits/stdio-lock.h (which 
includes lowlevellock.h, which isn't supposed to be used outside glibc) 
as /usr/include/bits/stdio-lock.h -- causing anything that (indirectly) 
includes <bits/stdio-lock.h> (such as glibc's own <libio.h> if _IO_MTSAFE_IO 
is defined).

Installing the generic bits/stdio-lock.h instead of the version in 
nptl/sysdeps/pthread/bits/stdio-lock.h as /usr/include/bits/stdio-lock.h 
should fix the problem without needing to make private headers public.

Alternatively, don't install bits/stdio-lock.h at all and make sure libio.h 
doesn't include it (if you consider _IO_MTSAFE_IO another "don't use this 
outside glibc" thing, a
#ifdef _IO_MTSAFE_IO
#error Don't use _IO_MTSAFE_IO outside glibc
#endif
bit would be far more helpful to someone not familiar with glibc internals 
than a failing #include <lowlevellock.h> (which will just tempt users to "fix" 
it the wrong way, by copying in lowlevellock.h, causing more bad code).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
            Summary|lowlevellock.h not installed|Wrong stdio-lock.h installed
            Version|2.3.3                       |2.4


http://sourceware.org/bugzilla/show_bug.cgi?id=245

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/245] Wrong stdio-lock.h installed

[bero at arklinux dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bero at arklinux dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=245

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/245] Wrong stdio-lock.h installed

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-02-18 04:01 -------
All has been said.  Modify your installation if you must.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=245

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.