Bugzilla Bug 114552

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!