This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bits/libc-lock.h and _LIBC


On Mon, Nov 04, Ulrich Drepper wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thorsten Kukuk wrote:
> 
> > We install libc-lock.h into /usr/include/bits. But libc-lock.h is
> > only useable, if it is compiled with -D_LIBC, which breaks now with
> > libio.h.
> 
> What exactly fails?  And when did it change?  The header is in this form
> installed on my systems and I have no problems using <libio.h>.

The nss_db package, for example.
libio.h uses some glibc internal things like attribute hidden, if
_LIBC is defined, but without _LIBC defined, bits/libc-lock.h use
useless.

 
> > I suggest the following patch, or is there any reason for the
> > ifdef _LIBC around __libc_lock_t ? We don't do this for __libc_key_t
> > and all the other definitions.
> 
> I've made the types opaque back when for a good reason.  I think it was
> mainly the use in libstdc++ but also to prevent any kind of initializers.

Than do it for all or for nothing. If you currently wish to use
libc-lock.h, you need to define _LIBC, but if you do this, you
cannot include something, which includes libio.h, afterwards.

The current bits/libc-lock.h behavior is inconsistent.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrnstr. 15-19        D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]