This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Gold on PowerPC checks/merges long double FP ABI tag across shared libraries
- From: "Daniel Kolesa" <daniel at octaforge dot org>
- To: binutils at sourceware dot org
- Date: Tue, 10 Dec 2019 17:16:03 +0100
- Subject: Gold on PowerPC checks/merges long double FP ABI tag across shared libraries
Hello,
I'm sending this here because I'm not sure how much of an intended behavior this is.
So, here's the problem: gold on PowerPC (either 32/64/64le) checks and merges the FP ABI tag across shared libraries as well as across regular object files . This is different from what bfd behaves like, which only checks and merges it for actual object files. I suspect that the bfd behavior is correct here - for one, static and shared linking behavior should be the same, and also sometimes you need an external shared library compiled with 128-bit FP ABI and your application with 64-bit FP ABI and know the symbols won't be used.
Notable cases include the musl libc, which only supports 64-bit long double, but libgcc_s.so still needs to be compiled with 128-bit FP ABI in order to include the IBM softfp emulation functions for TFmode; or, glibc supports both 64-bit and 128-bit long double ABI at once and will redirect the symbols depending on what you compile your thing with.
Example:
$ echo "void foo(long double x) {}" > test.c
$ gcc test.c -o test.so -shared -mlong-double-64
$ gcc test.c -o test.so -shared -mlong-double-64 -fuse-ld=gold
/bin/ld.gold: error: /tmp/ccsHdyhv.o uses 64-bit long double, /usr/lib/gcc/powerpc64le-linux-gnu/9.2.0/../../../../lib/libgcc_s.so.1 uses 128-bit long double
/bin/ld.gold: error: /tmp/ccsHdyhv.o uses 64-bit long double, /usr/lib/libc.so.6 uses 128-bit long double
collect2: error: ld returned 1 exit status
$ gcc test.c -o test.so -shared -mlong-double-64 -fuse-ld=gold -static-libgcc
/bin/ld.gold: error: /tmp/cc3AcDER.o uses 64-bit long double, /usr/lib/libc.so.6 uses 128-bit long double
collect2: error: ld returned 1 exit status
Regards,
Daniel Kolesa