I'm running a stable x86 system that has been upgrade to an new Pentium4 with 1.5GB RAM. To use the RAM optimal I have used crossdev to emerge an 64bit toolchain to build a 64bit kernel. That has worked without problems. On 29.5. gcc 3.4.6-r1 was marked x86 stable and emerge -DN world also wants to upgrade the crosscompiler, but that fails with the following message: 'glibc' was detected w/out ssp, that sucks (a lot) As far I can tell manually the 64bit glibc does contain the stack protector, it seems the logic to detect ssp on crosscompile is backward: From eclass/toolchain.eclass: # Check for gcc-3.x style ssp support if [[ -n $(readelf -s "${my_libc}" 2>/dev/null | \ grep 'OBJECT.*GLOBAL.*__guard') ]] && \ [[ -n $(readelf -s "${my_libc}" 2>/dev/null | \ grep 'FUNC.*GLOBAL.*__stack_smash_handler') ]] then return 0 elif is_crosscompile ; then die "'${my_libc}' was detected w/out ssp, that sucks (a lot)" else return 1 fi I read this as: IF there is no SSP: return 0 (==no SSP) ELSEIF: When crosscompiling: die "No SSP" ELSE: return 1 (==has SSP) Shouldn't this be: IF there is no SSP: IF crosscompiling: die "No SSP" ELSE return 0 (==no SSP) ELSE return 1 (==has SSP) The usages of libc_has_ssp seem to assume 1==has SSP, 0==no SSP: Like line 832/833: want_libssp && libc_has_ssp && \ die "libssp cannot be used with a glibc that has been patched to provide ssp symbols" Or is my interpretation backward? (-:
no ... it's using shell true/false ... return 0 -> true (has SSP) in the libc_has_ssp() func, add 'set -x' to the top of it and then post the debug output as a log file
I have no access to that computer until monday, so I tried to recreate this setup on my local pc. Trying to emerge the needed crosscompiler I hit the following problem: cross-x86_64-pc-linux-gnu/linux-headers-2.6.11-r2 will be merge into /usr/x86_64-pc-linux-gnu/usr/include/linux/ (See the following changeset: http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/kernel-2.eclass?r1=1.167&r2=1.168 ) But cross-x86_64-pc-linux-gnu/glibc-2.3.6-r3 will still check /usr/x86_64-pc-linux-gnu/include/linux/ to see if >=linux-headers-2.6.11 is installed (beacuse of NPTL) From glibc-2.3.6-r3.ebuild: alt_headers() { if [[ -z ${ALT_HEADERS} ]] ; then if is_crosscompile ; then ALT_HEADERS="/usr/${CTARGET}/include" else ALT_HEADERS="/usr/include" fi fi echo "${ALT_HEADERS}" } The following glibc ebuilds contain the new /usr/${CTARGET}/usr/include: 2.3.6-r4, 2.4-r2, 2.4-r3 All other ebuilds still look at /usr/${CTARGET}/include (incluing 2.4-r1 !) So the stable linux-headers will no longer work with the stable glibc. :( I made a symlink from /usr/x86_64-pc-linux-gnu/include -> /usr/x86_64-pc-linux-gnu/usr/include , now the glibc is building... I report with additional infos as soon as that is done.
known feature, all glibc versions older than 2.4-r3 and 2.3.6-r4 will not work with cross-compiling
glibc has been emerge, emerging gcc fails with the same error. Here is the trace from set -x: + update_gcc_for_libc_ssp + libc_has_ssp + local libc_prefix ++ tc-arch ++ tc-ninja_magic_to_arch portage ++ local type=portage ++ local host= ++ [[ -z '' ]] ++ host=x86_64-pc-linux-gnu ++ case ${host} in ++ ninj x86_64 amd64 ++ [[ portage == \k\e\r\n ]] ++ echo amd64 + [[ amd64 == \p\p\c\6\4 ]] ++ get_libdir ++ local CONF_LIBDIR ++ '[' -n '' ']' ++ get_abi_LIBDIR ++ get_abi_var LIBDIR ++ local flag=LIBDIR ++ local abi ++ '[' 1 -gt 1 ']' ++ '[' -n '' ']' ++ '[' -n amd64 ']' ++ abi=amd64 ++ local var=LIBDIR_amd64 ++ echo lib64 + libc_prefix=lib64 + libc_prefix=lib64 + echo 'int main(){}' + gcc /var/tmp/portage/gcc-3.4.5-r1/temp/libctest.c -lc -o libctest ++ readelf -d libctest ++ grep 'NEEDED.*\[libc\.so[0-9\.]*\]' ++ awk '{print $NF}' + local 'libc_file=[libc.so.6]' + libc_file=libc.so.6 + local my_libc=//lib64/libc.so.6 ++ readelf -s //lib64/libc.so.6 ++ grep 'FUNC.*GLOBAL.*__stack_chk_fail' + [[ -n '' ]] ++ readelf -s //lib64/libc.so.6 ++ grep 'OBJECT.*GLOBAL.*__guard' + [[ -n '' ]] + is_crosscompile + [[ i686-pc-linux-gnu != x86_64-pc-linux-gnu ]] + diefunc libc_has_ssp 512 0 ''\''//lib64/libc.so.6'\'' was detected w/out ssp, that sucks (a lot)' + local funcname=libc_has_ssp lineno=512 exitcode=0 + shift 3 + echo + echo '!!! ERROR: cross-x86_64-pc-linux-gnu/gcc-3.4.5-r1 failed.' !!! ERROR: cross-x86_64-pc-linux-gnu/gcc-3.4.5-r1 failed. Mmh... My 64bit libc.so.6 has been installed as /usr/x86_64-pc-linux-gnu/lib64/libc.so.6 readelf does find guard-pages: readelf -s /usr/x86_64-pc-linux-gnu/lib64/libc-2.3.6.so |grep guard 633: 0000000000223bd0 8 OBJECT GLOBAL DEFAULT 32 __guard@@GLIBC_2.3.2 786: 000000000001c920 159 FUNC GLOBAL DEFAULT 11 __guard_setup@@GLIBC_2.3.2 The local variable my_libc in libc_has_ssp is initialize to: local my_libc=${ROOT}/${libc_prefix}/${libc_file} But I can't find any references to take crosscompiling into account. The glibc-2.3.6-r3.ebuild uses alt_libdir() to calculate the path when referencing ${ROOT}, but I can't find anything using CTARGET in the gcc-ebuild.
Comment #3: The annoying part of that breakage is, that I have already successfully crosscompiled a stable glibc-2.3.6-r3 , only the change from 2006-04-09 to kernel-2.eclass broke it, as it not only changed the position of the unstable linux-headers but also the stable linux-headers. With the symlink hack I was able to compile the older glibc. I do not expect that this breakage with the headers can be fixed, later stableing a newer glibc seems to be the best way in that case. But I hope it is possible to fix the missdetection of the SSP. :)
fixed in cvs
