Created attachment 484902 [details] emerge --info '=sys-auth/elogind-231.4::gentoo' + first and last 500 lines of build.log Seems that by default elogind's autoconf tests for LTO support and enables it This causes the build to fail with many "undefined reference" errors on my setup Adding --disable-lto to econf fixes this for me
The "undefined reference" is a result of "plugin needed to handle lto object" on your machine. This is a bit surprising. I see you are using gcc-5.4. I am using gcc-6.3, and never had such a problem. I could add an explicit -fuse-linker-plugin, the build system already tells libtool to use the gold linker. But according to the docs: "This option is enabled by default when LTO support in GCC is enabled and GCC was configured for use with a linker supporting plugins (GNU ld 2.21 or newer or gold)." According to the output of "equery u" on binutils and gcc, there is no special USE flag to enable LTO support, it should be always there... So I am clearly overlooking something, because it should just work on your system. What you could check is the output of (mine included): $ ls -lh /usr/libexec/gcc/x86_64-pc-linux-gnu/*/*lto* -rwxr-xr-x 1 root root 992 19. Jun 14:55 /usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/liblto_plugin.la lrwxrwxrwx 1 root root 22 19. Jun 14:56 /usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/liblto_plugin.so -> liblto_plugin.so.0.0.0 lrwxrwxrwx 1 root root 22 19. Jun 14:56 /usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/liblto_plugin.so.0 -> liblto_plugin.so.0.0.0 -rwxr-xr-x 1 root root 67K 19. Jun 14:56 /usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/liblto_plugin.so.0.0.0 -rwxr-xr-x 1 root root 23M 19. Jun 14:56 /usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto1 -rwxr-xr-x 1 root root 832K 19. Jun 14:56 /usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper $ ls -lh /usr/x86_64-pc-linux-gnu/binutils-bin/2.28/*ld* lrwxrwxrwx 1 root root 6 20. Jul 09:38 /usr/x86_64-pc-linux-gnu/binutils-bin/2.28/ld -> ld.bfd -rwxr-xr-x 1 root root 993K 8. Jun 12:17 /usr/x86_64-pc-linux-gnu/binutils-bin/2.28/ld.bfd -rwxr-xr-x 1 root root 4,3M 8. Jun 12:17 /usr/x86_64-pc-linux-gnu/binutils-bin/2.28/ld.gold You see, I am normally using the default bfd linker.
I see you have set CFLAGS="-march=broadwell -O3 -pipe" in your make.conf. Does the build succeed if you change to CFLAGS="-march=native -O2 -pipe" ?
Weird, it builds just fine now, same gcc, same binutils, same CFLAGS, any version of elogind from tree. Only thing I did is installed gcc 7 (but it's not enabled). I might have had a messed up binutils install? I didn't re-emerge it since then. I suppose it's safe to mark the bug as invalid, or should I post any other info?
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=baaed0f05e2275a73d120a03851e450c723c1d27 commit baaed0f05e2275a73d120a03851e450c723c1d27 Author: Mike Gilbert <floppym@gentoo.org> Date: Thu Jul 20 22:36:41 2017 -0400 sys-auth/elogind: disable lto Bug: https://bugs.gentoo.org/625226 Package-Manager: Portage-2.3.6_p23, Repoman-2.3.3_p1 sys-auth/elogind/elogind-229.6.ebuild | 1 + sys-auth/elogind/elogind-231.4.ebuild | 1 + sys-auth/elogind/elogind-232.3.ebuild | 1 + 3 files changed, 3 insertions(+)
(In reply to Mike Gilbert from comment #4) > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=baaed0f05e2275a73d120a03851e450c723c1d27 > > commit baaed0f05e2275a73d120a03851e450c723c1d27 > Author: Mike Gilbert <floppym@gentoo.org> > Date: Thu Jul 20 22:36:41 2017 -0400 > > sys-auth/elogind: disable lto > > Bug: https://bugs.gentoo.org/625226 > Package-Manager: Portage-2.3.6_p23, Repoman-2.3.3_p1 > > sys-auth/elogind/elogind-229.6.ebuild | 1 + > sys-auth/elogind/elogind-231.4.ebuild | 1 + > sys-auth/elogind/elogind-232.3.ebuild | 1 + > 3 files changed, 3 insertions(+) Thank you Mike! On Gentoo LTO is normally used through the users choice of CFLAGS in their make.conf. I am about to prepare the 233.4 release, and maybe it would help if I adapted the detection like this: - Change the implicit enabling of LTO from finding any "-O*" in the environments CFLAGS, to finding "-flto" there. --> This would then listen to gentoo users CLFAGS settings. The thing is, that "--disable-lto" simply disables the implicit enabling. Actually I was never comfortable with the systemd-team's decision to depend on a mere optimization flag. How about pimping the ebuilds by adding a USE flag, so that users, who have enabled LTO in their make.conf, can disable it if they find elogind to not build? And finally I am still not able to reproduce the whole issue. I hope I can do so one day, because I would really like to fix that reliably.
I don't see why any USE flag or configure code is necessary here. People who want LTO can add -flto to their CFLAGS. People who don't want LTO can leave it out.
Yeah... This happens if you had your head too deep into other peoples build systems... XD I totally forgot about that tiny detail, that the FLAGS from the users make.conf will be appended anyway. ;-)
