On 28 March 2014 16:19, Paolo Bonzini <pbonz...@redhat.com> wrote:
> This patch introduces a configure option to disable the stack protector
> entirely, and conditional stack protector flag selection (in order,
> based on availability): -fstack-protector-strong, -fstack-protector-all,
> no stack protector.
I've just noticed that this test doesn't correctly handle MacOSX clang.
For some reason that has this behaviour:
manooth$ clang -o /tmp/zz9 -Werror -fstack-protector /tmp/zz9.c
# OK, plain -fstack-protector works
manooth$ clang -o /tmp/zz9 -Werror -fstack-protector-strong /tmp/zz9.c
clang: error: argument unused during compilation: '-fstack-protector-strong'
# The strong variant isn't implemented
manooth$ clang -o /tmp/zz9 -Werror -fstack-protector-strong
/tmp/zz9.c -framework CoreFoundation
# ...but for some reason adding the -framework CoreFoundation argument
# suppresses the error!
This is bad because we have that framework argument as part of our
linker flags. Effectively this means that clang won't warn about the
argument at link time but will warn for every .c->.o compile (as well
as ending up with no stack protection).
Changing the test from doing a compile-and-link to just
compiling a single object seems to fix this:
manooth$ git diff
diff --git a/configure b/configure
index eb0e7bb..c85475f 100755
--- a/configure
+++ b/configure
@@ -1448,7 +1448,7 @@ done
if test "$stack_protector" != "no" ; then
gcc_flags="-fstack-protector-strong -fstack-protector-all"
for flag in $gcc_flags; do
- if compile_prog "-Werror $flag" "" ; then
+ if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then
QEMU_CFLAGS="$QEMU_CFLAGS $flag"
LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag"
break
However perhaps the correct fix is to make MacOSX put
the -framework options in CFLAGS, not LDFLAGS -- they
seem (from what I can gather from google, which is not much)
to be a sort of combination of include files and libraries so should
probably be consistently specified everywhere.
thanks
-- PMM
