[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Undefined use of weak symbols in gnulib
From: |
Bruno Haible |
Subject: |
Re: Undefined use of weak symbols in gnulib |
Date: |
Sat, 17 Jul 2021 18:39:32 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; ) |
Hi Florian,
> > 1) I understand that it's only for glibc >= 2.34 on Linux (NPTL),
> > right? Not on Hurd (HTL)?
>
> Yes, Hurd hasn't been integrated.
>
> > 2) /usr/include/gnu/lib-names.h still defines LIBPTHREAD_SO.
> > How about not defining LIBPTHREAD_SO, since linking with it is supposed
> > to be a no-op in these newer glibc versions?
>
> I'm not sure if this is the right way, given that the file still exists
> for all currently supported targets.
Thanks for the rapid answers.
> An alternative would be to add a macro to <pthread.h>, such as
> PTHREAD_IN_LIBC.
This would be useful, yes. Like there is a <gnu/stubs.h> that gives meta-
information about functions that are stubs, it is useful to have a way
to find out whether a library is a stub. For cross-compilation scenarios,
implementing it through a macro in some header file is better than
implementing it through some file in /lib/ on the file system.
Bruno
Re: Undefined use of weak symbols in gnulib, Bruno Haible, 2021/07/17