sys-apps/module-init-tools-3.0_pre10 fails to compile with -fstack-protector in CFLAGS. This turns on stack smashing protection in GCC (propolice). I tried it without that flag, and it emerged fine. Attached is the log of it failing with -fstack-protector on. Portage 2.0.50-r1 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r9, 2.6.4) ================================================================= System uname: 2.6.4 i586 AMD-K6(tm) 3D processor Gentoo Base System version 1.4.3.10 distcc 2.13 i486-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-fstack-protector -O3 -march=i586 -pipe -mmmx -m3dnow" CHOST="i486-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-fstack-protector -O3 -march=i586 -pipe -mmmx -m3dnow" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache distcc notitles sandbox" GENTOO_MIRRORS="http://gentoo.seren.com/gentoo http://gentoo.noved.org/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://gentoo.mirrors.pair.com/ http://mirrors.tds.net/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow apache2 apm arts avi berkdb crypt encode foomaticdb gdbm gpm libg++ libwww mad mikmod mmx motif mysql ncurses oggvorbis pam perl python quicktime readline sdl slang snmp spell ssl tcpd truetype x86 xml2 zlib"
Created attachment 27334 [details] Portage Log with -fstack-protector
Please update your gcc from gcc-3.2.3-r2 to something more current (3.3.x) (gentoo-current would be ideal) and entire toolchain. I think this will also require a rebuild of glibc so you might as well so you might just want to get binutils in as well. Try again and report result here please. happy CPU cycles.
Sure, I can do that. Only one thing. When you say toolchain, what exactly do you mean?
binutils/gcc/glibc http://dev.gentoo.org/~solar/toolchain/images/compile_stages.jpg
Here is the kicker. After you rebuild the glibc for the first time you might want to rebuild the gcc after that. something like building in this order comes to mind. emerge binutils gcc glibc source /etc/profile env-update emerge gcc CFLAGS="-fstack-protector-all" emerge mod-init-tools You probably don't have to (fixes something else that comes to mind).. But hey CPU cycles don't cost that much these days right :) Anyway any gcc after the 3.2.3-r5 is ok but it nice to try and get many users on the same playing field as we can. Your probably going to have to do your first system wide check/scan for __guard@GCC when you hit gcc one of the two times. If that happens to you have get rid of old programs that are linked to the old __guard symbols that were found in libgcc.a.. This is documented in our bugzilla Again good luck. :)
Hrm. i went to do this in the order you stated, and gcc failed. I'm attaching the portage log.
Created attachment 27389 [details] Portage Log; gcc 3.3.3 failing
Can you try again with a standard set of cflags? like CFLAGS="-O2" emerge gcc
same for CXX
Okay, doing so. Thanks for sticking through this with me.
Okay, i tried CFLAGS="-O2" CXXFLAGS="-O2" emerge gcc, and it has failed again. Attaching another portage log.
Created attachment 27400 [details] Portage log, gcc failing after CFLAGS="-O2" CXXFLAGS="-O2" emerge gcc
Hm. I got a hunch, and killed off distcc. gcc then compiled. Now moving on, will report the results.
Okay, finished all that, and module-init-tools now emerges with -fstack-protector-all in CFLAGS. Question; did the flag to turn on propolice features change in gcc 3.3.3? According to the propolice page, it is -fstack-protector . On a somewhat related note i'm upgrading gcc and glibc and binutils on my other system, so i can be confident in using distcc. Unfortunately i'm having to recompile a lot of apps due to using -fstack-protector on most of them.
What you asked me to do solved the problem so this bug could be closed. Perhaps -fstack-protector could be filtered out in the ebuild if using gcc 3.2, and/or a notice as well.
Closing, then.
