[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Undefined use of weak symbols in gnulib

From: Florian Weimer
Subject: Re: Undefined use of weak symbols in gnulib
Date: Tue, 27 Jul 2021 22:19:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

* Joseph Myers:

> On Sat, 17 Jul 2021, Bruno Haible wrote:
>> 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 think LIBPTHREAD_SO is really for use with dlopen (followed by e.g. 
> using dlsym to look up a function by name at runtime), not linking against 
> (in general you need to link against the *.so name which might be a linker 
> script, not directly against the shared library's SONAME).
> So if there's any change regarding LIBPTHREAD_SO, I think the natural one 
> would be to define it to LIBC_SO (I hope the dlopen/dlsym case works 
> regardless of whether that change is made or not).

That is in an interesting idea.  I like it.

It doesn't help with Bruno's use case, detecting the integrated
libpthread with the preprocessor.

Carlos, do you think we can still slip in a definition of
PTHREAD_IN_LIBC in <pthread.h> (for __USE_GNU)?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]