This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Fix float128 IFUNC relocations on ppc64le [BZ #21707]
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