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.
Fix gcc. This header is not for userlevel code.
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.)
Don't reopen. If you don't like the answer, go somewhere else.
"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.
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).
All has been said. Modify your installation if you must.