libtool: link: x86_64-pc-linux-gnu-gcc -pipe -Wall -Wextra -Wundef -Wformat=2 -Wformat-security -Wformat-nonliteral -Wlogical-op -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=missing-declarations -Werror=return-type -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wno-format-signedness -Werror=overflow -Wdate-time -Wnested-externs -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden -fstack-protector -fstack-protector-strong -fPIE --param=ssp-buffer-size=4 -Werror=shadow -flto -ffunction-sections -fdata-sections -O2 -pipe -march=native -Wall -Wl,--gc-sections -Wl,--no-undefined -Wl,-z -Wl,relro -Wl,-z -Wl,now -pie -Wl,-fuse-ld=gold -Wl,-O1 -o test-login src/libelogind/sd-login/test-login.o -Wl,--as-needed ./.libs/libshared.a -ldl -lm -lresolv -ludev -lacl -lcap -pthread /var/tmp/portage/sys-auth/elogind-229.3/temp/ccYhKf1V.ltrans0.ltrans.o:<artificial>:function main: error: undefined reference to 'elogind_set_program_name' ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0-libressl_20170527-175314 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.3.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback)
Created attachment 474536 [details] emerge-info.txt
Created attachment 474538 [details] config.log.tbz2
Created attachment 474542 [details] emerge-history.txt
Created attachment 474544 [details] environment
Created attachment 474546 [details] etc.portage.tbz2
Created attachment 474548 [details] sys-auth:elogind-229.3:20170528-103529.log
Created attachment 474550 [details] temp.tbz2
I just rebuilt elogind-229.3 with your exact configure call, and it built flawlessly, using gcc-6.3.0. The resulting differences between both calls to libtool are: 1) -flto -ffunction-sections -fdata-sections 2) -Wl,--gc-sections -Wl,-O1 I have everything else, too. As systemd enforces the usage of the gold linker, let's see whether the LTO enforcement is creating the issue here. Results: - Adding 1) to CFLAGS does not lead to any problems. - Adding 2) to LDFLAGS does not lead to any problems. I am sorry, but apart from me having '-ftree-vectorize' in the CFLAGS, there is no difference now, and I can not reproduce your problem.
Created attachment 474862 [details] emerge.log.gz elogind emerged at his image too successfully after that failure - I attached the emerge..log for completeness
If I understand the log right, it looks like: - emerge elogind-229.3 - FAILED - emerge elogind-226.4 - success - update to elogind-229.3 - success Weird. I have searched for a few (ok, obvious) package upgrades between the failed and the successful merge, but nothing sticks out. Maybe it was jut a badly written byte? Murphy's Law? Really, I am completely at sea here, sorry.
This looks like it might be LTO-related.
(In reply to Michael Palimaka (kensington) from comment #11) > This looks like it might be LTO-related. The weird thing is, that the systemd build system always enforced LTO where available. @Toralf: Can you, by any chance, reproduce this error? "elogind_set_program_name()" is a function of mine to circumvent problems with musl-libc and to add debug log support for some internal parts.
(In reply to Sven Eden from comment #12) > (In reply to Michael Palimaka (kensington) from comment #11) > > This looks like it might be LTO-related. > > The weird thing is, that the systemd build system always enforced LTO where > available. ...and the systems team disabled it as soon as they noticed.
(In reply to Michał Górny from comment #13) > (In reply to Sven Eden from comment #12) > > (In reply to Michael Palimaka (kensington) from comment #11) > > > This looks like it might be LTO-related. > > > > The weird thing is, that the systemd build system always enforced LTO where > > available. > > ...and the systems team disabled it as soon as they noticed. Maybe, but LTO worked on all my machines with gcc-4.9.x, gcc-5.3.0 and now gcc-6.3.0 flawlessly. However, I *think* I found the reason. Let me do some experiments...
Two updates: 1) I think I found the reason. The fix will be included in version 231. 2) elogind, contrary to systemd, supports configure --disable-lto -> Please use this when in doubt. However, I am still not able to reproduce the issue, so 1) is guesswork. Hopefully someone can provide a reproducible way to trigger the linker error.
(In reply to Sven Eden from comment #15) > 1) I think I found the reason. The fix will be included in version 231. I have backported the possible "fix" to v229.5 and opened a version bump request as bug 621596. Could you please test whether the issue remains once elogind is bumped to v229.5? It *should* be fixed now.