sys-fs/udev (and more than likely also systemd, as this is from main systemd configure) fails on ARM with gnu2 tls-dialect, because ld.gold doesn't seem to support those relocations yet. Yet configure merely checks for -Wl,-fuse=gold argument presence on gcc and just explicitly forces it on without testing it actually works for it. Fortunately the LDFLAGS ordering is so that I can revert it in my own LDFLAGS. It might be hard to actually test for this, as it might depend on what is being linked - do those relocations get generated by -mtls-dialect=gnu2 or not in the test program. Either way, I believe in Gentoo it mustn't make the choice itself, as we support choosing the linker (bfd or gold) ourselves, and that choice ought to be honored by things being emerged (linked).
checking if armv7a-hardfloat-linux-gnueabi-gcc -std=gnu99 supports flag -Wl,-fuse-ld=gold in envvar LDFLAGS... yes It actually does try to link a program with it, but it consists of only "int main(void) { return 0; }", so that succeeds. Either way, there's the "In Gentoo we make our own choice of linker" argument :)
Created attachment 396392 [details] compressed build.log /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.9.2/../../../../armv7a-hardfloat-linux-gnueabi/bin/ld.gold: error: ./.libs/libudev-core.a(libsystemd_internal_la-sd-id128.o): unsupported reloc 91 against local symbol ./.libs/libudev-core.a(libsystemd_internal_la-sd-id128.o):sd-id128.c:function sd_id128_get_machine: error: cannot relocate unimplemented reloc R_ARM_TLS_CALL in object file etc
Created attachment 396400 [details, diff] Remove -fuse-ld=gold from linker flags. This patch against systemd's codebase should do it. I haven't tested it, but I'm like 99% sure it will work. There are some significant difference between bfd and gold and it will bite use it situations like this or if we try to mix static+pie on hardened etc. @Reporter. Can you test if it fixes things on your arm board?
Please report this with systemd upstream so that everyone can benefit.
(In reply to Mike Gilbert from comment #4) > Please report this with systemd upstream so that everyone can benefit. Doubt that will fly. I'll ask in the #systemd channel why gold and if bfd will work, but I'm not going to open a bug report with systemd people to have it ignored.
(In reply to Anthony Basile from comment #5) > (In reply to Mike Gilbert from comment #4) > > Please report this with systemd upstream so that everyone can benefit. > > Doubt that will fly. I'll ask in the #systemd channel why gold and if bfd > will work, but I'm not going to open a bug report with systemd people to > have it ignored. If you document a build scenario that fails, I think it has a good shot of getting fixed. Starting with "why do you force gold" might not be the best approach; it presupposes that the problem can only be solved in one way.
*** Bug 545168 has been marked as a duplicate of this bug. ***
bug 545168 also shows failure with LDFLAGS="-Wl,--sort-section=alignment"
This also breaks sparc, i.e. without adding cc_cv_LDFLAGS__Wl__fuse_ld_gold=no to the environment you can't build a working udev (216 or 225) on sparc.
Again, document the failure and open an issue upstream please.
(In reply to Mart Raudsepp from comment #8) > bug 545168 also shows failure with LDFLAGS="-Wl,--sort-section=alignment" You should have made it clear that it means user-provided LDFLAGS. Well, this is one good reason why we shouldn't let upstream change linker implicitly unless using bfd breaks something. I'm going to test disabling it. I'm also going to look into upstream tests and possibly submit improvements.
I've reported the underlying problem upstream [1] and got it fixed in 24hrs. But yes, it's better to complain how bad systemd upstream is than try. Not saying we shouldn't disable gold anyway. But at least it should now detect correctly that it conflict with user's LDFLAGS. [1]:https://github.com/systemd/systemd/pull/2541
This was fixed a long time ago.
