Re: [PATCH] BZ #5784: Build libpthread.a with ld -r

[Roland McGrath <roland at hack dot frob dot com>]

> It should be possible to fix this sort of static linking issue by defining 
> internal-use aliases and using them instead of directly using the symbols 
> with such warnings.  The alias would in this case only need to be defined 
> / used for static linking, though it might be simpler to export it from 
> shared libc as GLIBC_PRIVATE and use it unconditionally.

I think we should do that, independent of the larger static -lpthread
issue.  There is no reason that a user program that calls library function
A and never calls library function B should get a linker warning that talks
about B.  

This is a case where the comment in the code indicates that the usage is
actually safe and so the warning really doesn't apply.  In such cases,
there should just be no warning, as would happen from using an internal
symbol name as you suggest.

If there are other cases where a warning is issued that is actually
apropos, still it should be done differently so that the only warning
issued is one that refers to the interfaces the user actually called rather
than ones that are implementation details of what the user actually called.

It should be reasonably straightforward to write a script that audits for
such cases.  That is, run something like readelf -S on lib*.a to collect
all the .gnu.warning.foo names, and then something like readelf -r on
lib*.a to find all references to each foo.  That could even be part of
'make check'.


Thanks,
Roland