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

["bero at arklinux dot org" <sourceware-bugzilla at sourceware 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.