Re: [RFC] Fix float128 IFUNC relocations on ppc64le [BZ #21707]

[Joseph Myers <joseph@codesourcery.com>]

On Wed, 5 Jul 2017, Florian Weimer wrote:

> On 07/05/2017 09:25 PM, Carlos O'Donell wrote:
> >>> +# libgcc requires __tcb_parse_hwcap_and_convert_at_platform when built with
> >>> +# a binary128 type.  That symbol is provided by the loader on dynamically
> >>> +# linked executables, forcing to link the loader after libgcc link.
> >>> +f128-loader-link = $(as-needed) $(elf-objpfx)ld.so $(no-as-needed)
> >> Why doesn't the regular linker invocation take care of this?  Will user
> >> applications run into the same issue?
> > We don't use the regular linker invocation in glibc builds? We have to emulate
> > what the actual toolchain would do in this case.
> 
> But then we should do this everywhere, and not just for the few tests
> that actually need it, right?  I assume that's also what the official
> linker script does.

The installed compiler does -lgcc -lc -lgcc (roughly; -lgcc may actually 
use -lgcc_s or -lgcc_eh, and -lc may vary for e.g. profiling).  -lc is a 
linker script doing e.g. GROUP ( /lib64/libc.so.6 
/usr/lib64/libc_nonshared.a  AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) ).  
The shared libgcc is also a linker script on some platforms.

The glibc build uses libc.so --as-needed ld.so --no-as-needed -lgcc 
(again, roughly) (but libc.a -lgcc libc.a -lgcc in the static build case).

I suppose the suggestion is that we should both use -lgcc before linking 
with libc, not just after (this being the issue involved in the present 
case), and use -Wl,--start-group -Wl,--end-group around libc.so and ld.so, 
both to be more similar to how things work with the installed compiler?  
Which makes sense, but is also rather risky for this development stage.

-- 
Joseph S. Myers
joseph@codesourcery.com