We've seen this on aarch64 and s390x, but it isn't an architecture specific issue, but a bug in ld.bfd... the reason armv7hl, ppc64 and x86 don't see it is they end up using ld.gold instead of the bfd linker when using -flto (I've reproduced the failure on x86_64 by removing ld.gold in the chroot to ensure ld.bfd is called.) It appears to be some kind of awful interaction between ld plugins, indirect functions, and ld warnings. Hooray. :/ libtool: link: gcc -shared -fPIC -DPIC .libs/libsystemd_journal_la-libsystemd-journal.o -Wl,--whole-archive ./.libs/libsystemd-journal-internal.a ./.libs/libsystemd-internal.a ./.libs/libsystemd-shared.a -Wl,--no-whole-archive -llzma -lgcrypt -lgpg-error -lrt -ldw -ldl -flto -O2 -m64 -mtune=generic -Wl,--as-needed -Wl,--no-undefined -Wl,--gc-sections -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--version-script=../src/compat-libs/libsystemd-journal.sym -Wl,-z -Wl,relro -pthread -Wl,-soname -Wl,libsystemd-journal.so.0 -o .libs/libsystemd-journal.so.0.11.5 libsystemd_internal_la-bus-message.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters /tmp/ccvlhvDy.ltrans0.ltrans.o: In function `sd_journal_flush_matches': ccvlhvDy.ltrans0.o:(.text+0xf90): multiple definition of `sd_journal_flush_matches' libsystemd_journal_internal_la-sd-journal.o (symbol from plugin):(.text+0x0): first defined here /tmp/ccvlhvDy.ltrans0.ltrans.o: In function `sd_journal_add_match': ccvlhvDy.ltrans0.o:(.text+0x10d0): multiple definition of `sd_journal_add_match' libsystemd_journal_internal_la-sd-journal.o (symbol from plugin):(.text+0x0): first defined here /tmp/ccvlhvDy.ltrans0.ltrans.o: In function `sd_journal_add_conjunction': ccvlhvDy.ltrans0.o:(.text+0x15e0): multiple definition of `sd_journal_add_conjunction' libsystemd_journal_internal_la-sd-journal.o (symbol from plugin):(.text+0x0): first defined here /tmp/ccvlhvDy.ltrans0.ltrans.o: In function `sd_journal_add_disjunction': ccvlhvDy.ltrans0.o:(.text+0x1690): multiple definition of `sd_journal_add_disjunction' libsystemd_journal_internal_la-sd-journal.o (symbol from plugin):(.text+0x0): first defined here
This is fixed in binutils HEAD... I bisected the fix to 46135103, but it seems a little... unusual for 2.24 branch, so I'm unsure how to proceed. Going to spend the day trying to see if I can simplify the diff to fix this case without all the extra code. From 4613510308cea27713e8c7424b2afee9b99f6226 Mon Sep 17 00:00:00 2001 From: Alan Modra <amodra> Date: Tue, 12 Aug 2014 10:43:33 +0930 Subject: [PATCH 1/1] Change ld "notice" interface for better handling of indirect symbols The main aim of this change was to have non_ir_ref set correctly on new indirect symbols. I could have added a "copy" param to the "notice" function, so that indirect symbols could be created in plugin_notice, but it seemed cleaner to create indirect syms earlier and pass them rather than "string" to "notice". include/ * bfdlink.h (struct bfd_link_callbacks <notice>): Remove "string" param, add "inh". bfd/ * coff-aux.c (coff_m68k_aux_link_add_one_symbol): Only call "notice" here when not calling the generic add_symbol function. Formatting. Correct handling of indirect symbols. Update notice call. * elflink.c (_bfd_elf_notice_as_needed): Update notice call. * linker.c (_bfd_generic_link_add_one_symbol): Create indirect symbols early. Update notice call. Add comments regarding weak symbols vs. indirect. ld/ * ldmain.c (notice): Update args. * plugin.c (plugin_notice): Likewise. Follow warning sym link. Handle new indirect symbol.
I've shoved this into 2.24-23.fc22 & corresponding f21 version so we can rebuild the world with it on aarch64.