On 11 April 2014 15:33, Alexey Kardashevskiy <a...@ozlabs.ru> wrote: > On 04/12/2014 12:24 AM, Alexey Kardashevskiy wrote: >> This helps. No idea why. Any ideas? :) >> >> @@ -1448,7 +1452,7 @@ done >> if test "$stack_protector" != "no" ; then >> gcc_flags="-fstack-protector-strong -fstack-protector-all" >> for flag in $gcc_flags; do >> - if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then >> + if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC "" ; then >> QEMU_CFLAGS="$QEMU_CFLAGS $flag" >> LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" >> break
This change causes the do_cc to always fail (you can see the compiler errors in the logs as it fails to find a file whose name is the empty string), so it means we don't use the -fstack-protector arguments. >>> /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: >>> cannot find -lssp_nonshared >>> /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: >>> cannot find -lssp >>> collect2: error: ld returned 1 exit status If we do use the stack protector arguments then the next time we try to do a configure test which does a link then it fails like this, because your cross compile environment doesn't have the stack-protector libraries in it. You should probably add those, so you get the benefit of the stack protection, but we can work around this in configure by doing both a compile and a link check, as MST originally suggested. Patch to follow shortly. (Here's a linux perf tools patch which deals with a similar situation: https://lkml.org/lkml/2010/1/11/117 ) thanks -- PMM
