Valgrind links to libgcc, but not to glibc. If valgrind is built with a compiler that was itself built with SSP, then the build will fail because libgcc imports __guard and __stack_smash_handler while these symbols are exported by glibc. One way to solve this is to make sure that libgcc is not built with SSP. I've talked to solar and psm about this, and psm suggested the following changes to the toolchain.eclass in function do_gcc_SSP_patches(): # we apply only the needed parts of protectonly.dif - sed -e 's|^CRTSTUFF_CFLAGS = |CRTSTUFF_CFLAGS = -fno-stack-protector-all |'\ + sed -e 's|^CRTSTUFF_CFLAGS = |CRTSTUFF_CFLAGS = -fno-stack-protector |'\ -i gcc/Makefile.in || die "Failed to update crtstuff!" + sed -e 's|^\(LIBGCC2_CFLAGS.*\)$|\1 -fno-stack-protector|' \ + -i ${S}/gcc/Makefile.in || die "Failed to update gcc!" I am now looking for someone who can review these changes. For instance, I'm not sure if we should care if CRTSTUFF is also built without SSP, but I know that for valgrind it is not a requirement; the second part of the patch alone will solve my problem with valgrind.
the changes look fine/logical to me. Can you commit the changes Maurice?
Tried this on gcc-3.4.4-r1 so far; does what it says on the tin. /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/crt*.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libgcc.a /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libgcc_s.so.1 are all built without SSP, other stuff is unaffected (i.e. you still get SSP built into libffi, libg2c, libgcj and friends, libstdc++, which all need libc.so so they're fine as they are). With regards crt*.o, I think it makes good sense to avoid building SSP into those objects. One of the library switching options, "-nodefaultlibs" gets you crtbegin and crtend but no libc, so as with '-nostdlib' it would be up to the app to provide ssp support if it wanted it.
Kevin committed the changes to toolchain.eclass. Thanks guys!
