* 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