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)
 x86_64-pc-linux-gnu-6.3.0 *
Available Python interpreters, in order of preference:
 python2.7 (fallback)
Created attachment 474536 [details]
Created attachment 474538 [details]
Created attachment 474542 [details]
Created attachment 474544 [details]
Created attachment 474546 [details]
Created attachment 474548 [details]
Created attachment 474550 [details]
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.
- 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]
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
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
...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...
1) I think I found the reason. The fix will be included in version 231.
2) elogind, contrary to systemd, supports
-> 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.