[PATCH 05/13] powerpc64le: link tests against ld.so

[Joseph Myers]

On Mon, 9 Mar 2020, Paul E Murphy wrote:

> I don't disagree.  I think this workaround can be unilaterally added to
> gnulib-tests on ppc64le [1].  Though, I suspect that this is not the most
> accurate solution.
> 
> Looking at the comments in Makerules:
> 
> # Compiler arguments to use to link a shared object with libc and
> # ld.so.  This is intended to be as similar as possible to a default
> # link with an installed libc.
> 
> and poking around with GCC, I admit I don't fully understand all the
> (seemingly) implicit behavior of the default linking command.  Does:
> 
> -Wl,--as-needed $(elf-objpfx)ld.so -Wl,--no-as-needed ... -lgcc_s ...
> 
> accurately match the behavior of the default link command on ppc64le?

As I understand it, GCC does "-lgcc -lc -lgcc" (with various --as-needed 
etc. variations).  But glibc is doing something like "-lc -lgcc", and your 
patch is proposing adding an ld.so link to the makefile variable expanding 
to some form of -lgcc.  (In both cases, there is an as-needed ld.so link 
as part of the -lc link; directly in the linker command in the glibc case, 
via the libc.so linker script in the normal installed GCC case.)

So I wonder what would break if we added linking with libgcc before 
linking with libc in the relevant settings in glibc, which would seem 
closest to what installed GCC does by default.  When (across glibc 
architectures) does (static) libgcc define some symbols also defined by 
glibc's libc, and what would be the effects of linking first with libgcc 
and thus getting the libgcc versions of any such symbols instead of the 
libc ones?  And would linking with libgcc in that place (as well as after 
libc) fix the issue you see?

-- 
Joseph S. Myers
joseph@codesourcery.com