[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)?
Thanks,
Florian
Re: Undefined use of weak symbols in gnulib, Bruno Haible, 2021/07/17