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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

cvs-commit at gcc dot gnu.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
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
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


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