ld -T pie/pie.lds.S -o pie/parasite.built-in.bin.o pie/parasite.built-in.o pie/parasite.built-in.o: In function `init_thread': parasite.c:(.text+0xb8): undefined reference to `__stack_chk_fail' pie/parasite.built-in.o: In function `fini_thread': parasite.c:(.text+0x158): undefined reference to `__stack_chk_fail' pie/parasite.built-in.o: In function `sys_write_safe': parasite.c:(.text+0x1f7): undefined reference to `__stack_chk_fail' pie/parasite.built-in.o: In function `parasite_service': (.text+0xe82): undefined reference to `__stack_chk_fail' pie/parasite.built-in.o: In function `log_set_fd': (.text+0xf3f): undefined reference to `__stack_chk_fail' pie/parasite.built-in.o:(.text+0xf80): more undefined references to `__stack_chk_fail' follow # cat /var/db/pkg/sys-devel/gcc-4.7.2/USE abi_x86_64 amd64 cxx elibc_glibc graphite hardened kernel_linux multilib nls nptl openmp systemd userland_GNU -fno-stack-protector should be passed at this case
1) Please post your `emerge --info' output in a comment. 2) Please attach the entire build log to this bug report.
Created attachment 340664 [details] emere --info
Created attachment 340666 [details] eclass-debug.log
Created attachment 340668 [details] build.log
Created attachment 340670 [details] environment
Here is your problem: > -flto -fuse-linker-plugin You have ignored the warning: > LTO support is still experimental and unstable. > Any bugs resulting from the use of LTO will not be fixed. Create a file /etc/portage/env/no-lto with: CFLAGS="${CFLAGS} -fno-lto" CXXFLAGS="${CXXFLAGS} -fno-lto" LDFLAGS="${LDFLAGS} -fno-lto" Then create a file /etc/portage/package.env with: sys-process/crtools no-lto And then you can try again, the chance it is high that this will fix it. Am running 4.7.2 here as well; I should note you that LTO doesn't only result it typical build errors like these, it can silently generate corrupt libraries as well...
As I have -flto enabled world wide, of course I know that it's broken. So I check&disable it for broken packets at first. But that's not that case. For building this packet I use: # cat /etc/portage/env/security.conf CFLAGS="-O2 -march=core2 -fPIC -fno-stack-protector -Wno-error" CXXFLAGS="-O2 -march=core2 -fPIC -fno-stack-protector -Wno-error" LDFLAGS="-O1 -fno-stack-protector" # grep crtools /etc/portage/package.env/sys-process sys-process/crtools security.conf Disabling flto doesn't fix linking bug, of course.
(In reply to comment #7) > Disabling flto doesn't fix linking bug, of course. Then why does `wget https://bugs.gentoo.org/attachment.cgi?id=340668 -O build.log > /dev/null && grep -c flto build.log` not return 0?
Because that build log without flto disabled, of course.
Created attachment 340808 [details] build.log -- without flto
Okay, assigned to maintainers. It seems like http://stackoverflow.com/a/5090942/47064 is onto something, but I hope for you that it is not http://stackoverflow.com/a/5090913/47064 which is the result of compiling libraries getting corrupted by -fLTO. Been there, done that; bug #453938.
Closing as obsolete since this doesn't seem to be an issue with recent criu releases on hardened for me.