ld/ldlang.c lang_check calls bfd_merge_private_bfd_data from within a block conditional on bfd_count_sections (input_bfd). It makes sense to exclude relocatable objects without contents, but since shared libraries do not have sections loaded by the ELF linker (see elflink.c:4337 bfd_section_list_clear call), the condition stops .gnu.attributes processing for shared libraries. gold on the other hand does process .gnu.attributes for shared libraries.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=91ed9b71fa737ff4a4519f84c5e0ae0d544514f1 commit 91ed9b71fa737ff4a4519f84c5e0ae0d544514f1 Author: Alan Modra <amodra@gmail.com> Date: Fri May 1 15:17:42 2020 +0930 ppc32 merging of e_flags from dynamic objects EF_PPC_RELOCATABLE and similar flags, if present in an input shared library, don't have any relevance as far as the output file is concerned. Currently, dynamic objects aren't seen in merge_private_bfd_data. This patch is in preparation for a change to that. PR 25882 * elf32-ppc.c (ppc_elf_merge_private_bfd_data): Ignore e_flags from shared libraries.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6b728d3286a6e073e8cbdb63600e421de4f32dad commit 6b728d3286a6e073e8cbdb63600e421de4f32dad Author: Alan Modra <amodra@gmail.com> Date: Fri May 1 15:20:14 2020 +0930 FIXME for merging of e_flags and .gnu.attributes Code in the linker, present before the addition of .gnu.attributes support, results in shared libraries not being considered by BFD when merging e_flags and .gnu.attributes from input files to the output. That doesn't seem correct to me, but I don't know enough about all the various ABIs to change the behaviour with any confidence. So this patch merely punts on dynamic objects in merge_private_bfd_data target functions, with a FIXME for maintainer attention. I haven't excluded shared libraries from being considered where the target merge_private_bfd_data (a) already has code dealing with shared libraries, or (b) where that function just sets the output to the most constraining arch/mach combination and other fairly trivial merges, or (c) when the target has no shared library linker support. In (a) are: arc, arm, aarch64, riscv, sparc. In (b) are: bpf, cris, csky, m32r, m68k, mn10300, nios2, tilegx, tilepro, vax, visium, xtensa. In (c) are: bpf, cr16, h8300, iq2000, m32c, m68hc11, m68hc12, mcore, mep, msp430, mt, rl78, rx, v850. PR 25882 * elf32-bfin.c (elf32_bfin_merge_private_bfd_data): Add FIXME. * elf32-frv.c (frv_elf_merge_private_bfd_data): Likewise. * elfxx-mips.c (_bfd_mips_elf_merge_private_bfd_data): Likewise. * elf32-nds32.c (nds32_elf_merge_private_bfd_data): Likewise. * elf32-score.c (s3_elf32_score_merge_private_bfd_data): Likewise. * elf32-score7.c (s7_elf32_score_merge_private_bfd_data): Likewise. * elf32-sh.c (sh_elf_merge_private_data): Likewise. * elf32-tic6x.c (elf32_tic6x_merge_attributes): Likewise. * elf64-ia64-vms.c (elf64_ia64_merge_private_bfd_data): Likewise. * elfnn-ia64.c (elfNN_ia64_merge_private_bfd_data): Likewise.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a8acd6eeb6dc2cc5460ece90f90ebe36b56b20ba commit a8acd6eeb6dc2cc5460ece90f90ebe36b56b20ba Author: Alan Modra <amodra@gmail.com> Date: Fri May 1 15:23:17 2020 +0930 PR25882, .gnu.attributes are not checked for shared libraries This allows backend merge_private_bfd_data to examine shared library e_flags and/or .gnu.attributes. ARM and PowerPC have done so when using ld.gold for a long time. (The tic6x change below is dead code due to the earlier FIXME, but this is probably one of the changes needed there.) PR 25882 bfd/ * elf32-tic6x.c (elf32_tic6x_merge_attributes): Don't transfer Tag_ABI_PIC or Tag_ABI_PID from dynamic objects to the output. ld/ * ldlang.c (lang_check): Call bfd_merge_private_bfd_data for shared libraries.
Fixed.
It is odd to check .gnu.attributes on shared libraries since shared libraries used at link-time can be very different from run-time. Checking .gnu.attributes on shared libraries gives you very little. For PT_GNU_PROPERTY, .note.gnu.property section is ignored on shared libraries and shared library check is done at run-time.
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6f3fe02b0b8f6865820d8889a8420190063f3235 commit 6f3fe02b0b8f6865820d8889a8420190063f3235 Author: Alan Modra <amodra@gmail.com> Date: Fri May 22 11:42:43 2020 +0930 PowerPC: downgrade FP mismatch error for shared libraries to a warning PR 25882 bfd/ * elf32-ppc.c (_bfd_elf_ppc_merge_fp_attributes): Don't init FP attributes from shared libraries, and do not return an error if they don't match. gold/ * powerpc.cc (merge_object_attributes): Replace name param with obj param. Update callers. Don't init FP attributes from shared libraries, and do not emit an error if they don't match.
This should be reverted. It breaks linking anything that uses libgcc_s.so.1 on musl libc, since gcc builds ld128 floating point functions into libgcc unconditionally, but musl's ABI does not use them. (And in general it breaks any use of -mlong-double-64 in a setting where shared libgcc will be used.)
Also note that while, for musl targets, this issue could also be fixed just by getting gcc not to build its ld128 functions in libgcc_s, there are also people using glibc's ld64 ABI, and glibc necessarily has (as ABI) both ld64 and ld128 functions in the same shared library. So I don't think there's any complete fix without reverting this.
OK, I should have read more before commenting. My comments in particular pertain specifically to powerpc64 although other archs might be affected too. I see that the error was downgraded to a warning since the breaking change first appeared in a release, which is an improvement, but it's still likely going to lead to people doing very wrong things based on that warning. For example, Alpine Linux got this merge request: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13547 which would have created a broken Frankenstein-ABI to make the error message go away rather than fixing the problem. I can envision folks doing the exact same sort of thing when they see a warning, because I get/see wrong "warning fix" patches all the time for compiler warnings.
One fix is to compile libgcc_s_so.1 with -mno-gnu-attribute, which can be accomplished by adding gcc_s_compile += -mno-gnu-attribute to libgcc/config/rs6000/t-linux