Created attachment 490046 [details] output when running genkernel $ genkernel --version 3.4.52.4 $ genkernel --no-install --mrproper all fails (almost instantaneously) (see attachment)
Please reopen with your emerge --info output. Your gcc is not supporting -fstack-protector, which is weird, because that's standard in gentoo for a long time now.
*** Bug 627326 has been marked as a duplicate of this bug. ***
My original report: https://bugs.gentoo.org/show_bug.cgi?id=627326 Adding my emerge --info attachment. M.
Created attachment 492246 [details] emerge --info
Matt: Can you please show me the output of: # gcc-config -l # echo 'int main() {}' >/tmp/stacktest.c && gcc-5.4.0 -fstack-protector /tmp/stacktest.c -o /tmp/stacktest -v ; echo $?
If you aren't still using gcc 5.4.0 as your current GCC, please update the version as needed.
(In reply to Robin Johnson from comment #5) > Matt: > Can you please show me the output of: > # gcc-config -l > # echo 'int main() {}' >/tmp/stacktest.c && gcc-5.4.0 -fstack-protector > /tmp/stacktest.c -o /tmp/stacktest -v ; echo $? $ gcc --version gcc (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) 5.4.0 $ gcc-config -l [1] i686-pc-linux-gnu-5.4.0 * I'm attaching the output of your GCC test after submitting this comment. M.
Created attachment 492674 [details] Requested GCC Test Output
That output shows the -fstack-protector worked fine; so why did the kernel decide that it's not supported??? I'm moving this bug to the kernel team, because it's not a genkernel issue. kernel team: CONFIG_CC_STACKPROTECTOR_REGULAR is set by default in genkernel. It seems that for two systems now, the kernel outputs: "Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler" Yet using the compiler manually with -fstack-protector works fine.
If this is not reproducible without genkernel, I'm not sure what I can do here.
Hi, Robin, Adding you back as I hope you can help me. When I run the command on amd64, stackp-flag does not get set. When I run it on x86 (like reporter, it does get set). When stackp-flag is non empty (x86) it falls into the error around line 1086 in the Makefile: ifdef stackp-name ifeq ($(call cc-option, $(stackp-flag)),) @echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \ $(stackp-flag) not supported by compiler >&2 && exit 1 endif endif The question is how stackp-flag is empty for amd64 Still looking here
No, I'm wrong. The following function gives different values on x86 vs amd64: ifeq ($(call cc-option, $(stackp-flag)),) amd64: stackp-name: REGULAR stackp-flag -fstack-protector x86: stackp-name: REGULAR stackp-flag -fstack-protector but on amd64 the call function works, but on x86 it does not.
(In reply to Mike Pagano from comment #12) > No, I'm wrong. > > The following function gives different values on x86 vs amd64: > > > > ifeq ($(call cc-option, $(stackp-flag)),) > > amd64: > stackp-name: REGULAR stackp-flag -fstack-protector > > x86: > stackp-name: REGULAR stackp-flag -fstack-protector > > but on amd64 the call function works, but on x86 it does not. Which do you mean by function: the entire ifeq function evaluation, or just the cc-option call? I'm trying to find an x86 system that exhibits the problem, so I can poke at why. The one system I do have, doesn't exhibit it at all, but isn't an exact match to the gcc version.
Ok, this is something specific to the kconfig that shipped with old genkernel. Using genkernel-3.5.0.8 or newer and it works fine. I think something else that ends up in the gcc options is causing a failure when -fstack-protector is also added. Since the kernel doesn't print the commands options during cc-option evaluation, it's not so trivial to evaluate. I'm tempted to just close this bug, as genkernel-3.5 has lots of changes to go with the newer kernel sources. You'd need 3.5.2.0 for recent glibc changes as well.
(In reply to Robin Johnson from comment #14) > Ok, this is something specific to the kconfig that shipped with old > genkernel. Using genkernel-3.5.0.8 or newer and it works fine. > Well, folowing that logic, I bumped genkernl to 3.5.2.0-r1 (which wanted app-misc/pax-utils to be >=1.2.2 and sys-apps/util-linux to be static-libs). I put 4.13.0 sources on here (no easily "not conflict" with my running 4.12.10). The kernel is now building. It's still going so I can't say to 100% certain I won't get bit by some other oddity, but it's going which is a LOT more than it was. THANK YOU! M. P.S. Yes I know I need to move away from x86 and to _64. I'm just trying to decide what to do. This _hardware_ is indeed 64 bit. It's just this machine and I have been through quite a lot for a loooong time: me@aragorn ~ $ ls -lt --full-time /etc/ssh/ | tail -n5 -rw-r--r-- 1 root root 349 2002-10-17 16:45:54.000000000 -0400 ssh_host_key.pub -rw------- 1 root root 883 2002-10-17 16:43:11.000000000 -0400 ssh_host_rsa_key -rw-r--r-- 1 root root 240 2002-10-17 16:43:11.000000000 -0400 ssh_host_rsa_key.pub -rw------- 1 root root 672 2002-10-17 16:42:48.000000000 -0400 ssh_host_dsa_key -rw-r--r-- 1 root root 620 2002-10-17 16:42:48.000000000 -0400 ssh_host_dsa_key.pub Yes those dates are real. Same install, obviously many different hardwares in that time. I did the initial install with a Gentoo CD of an RC for 1.0. Seriously: me@aragorn ~ $ ls -l --full-time /README.maintainer -rw-r--r-- 1 root root 3473 2002-05-08 15:19:08.000000000 -0400 /README.maintainer me@aragorn ~ $ tail -n4 /README.maintainer Best Regards, Daniel Robbins drobbins@gentoo.org ;-)
(In reply to Robin Johnson from comment #13) > (In reply to Mike Pagano from comment #12) > > No, I'm wrong. > > > > The following function gives different values on x86 vs amd64: > > > > > > > > ifeq ($(call cc-option, $(stackp-flag)),) > > > > amd64: > > stackp-name: REGULAR stackp-flag -fstack-protector > > > > x86: > > stackp-name: REGULAR stackp-flag -fstack-protector > > > > but on amd64 the call function works, but on x86 it does not. > > Which do you mean by function: > the entire ifeq function evaluation, or just the cc-option call? > > I'm trying to find an x86 system that exhibits the problem, so I can poke at > why. The one system I do have, doesn't exhibit it at all, but isn't an > exact match to the gcc version. I'm fine with your plan to do the bump and move on with this one. But I do have an x86 system I can give you access to if you like that does exhibit the behavior. Not sure it's worth your effort.
Robin, I'm going to close this with the workaround that users can just upgrade genkernel. If you want to reopen and take assignment of it, please do.