Message ID | 20140410163132.GA28144@redhat.com |
---|---|
State | New |
Headers | show |
On 10 April 2014 17:31, Michael S. Tsirkin <mst@redhat.com> wrote: > On Wed, Apr 09, 2014 at 12:04:47PM +0100, Peter Maydell wrote: >> MacOSX clang silently swallows unrecognized -f options when doing a link >> with '-framework' also on the command line, so to detect support for >> the various -fstack-protector options we must do a plain .c to .o compile, >> not a complete compile-and-link. >> >> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > > Hmm it worries me a bit that we aren't passing it to linker: > might break some builds in case compiler has a working > protector but linker doesn't. Given we both compile and link (in configure) with the same $compiler binary, this seems vanishingly unlikely. > configure: check -c each time we run compiler > > Some warnings/errors only surface if you run compiler > without a linker. Run both on each test. > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > > diff --git a/configure b/configure > index eb0e7bb..8adc72b 100755 > --- a/configure > +++ b/configure > @@ -102,6 +102,7 @@ compile_object() { > compile_prog() { > local_cflags="$1" > local_ldflags="$2" > + do_cc $QEMU_CFLAGS -c $local_cflags -o $TMPO $TMPC > do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags > } > That's a lot of extra compiles and configure isn't exactly a speed demon as it is... thanks -- PMM
On Thu, Apr 10, 2014 at 05:37:31PM +0100, Peter Maydell wrote: > On 10 April 2014 17:31, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Wed, Apr 09, 2014 at 12:04:47PM +0100, Peter Maydell wrote: > >> MacOSX clang silently swallows unrecognized -f options when doing a link > >> with '-framework' also on the command line, so to detect support for > >> the various -fstack-protector options we must do a plain .c to .o compile, > >> not a complete compile-and-link. > >> > >> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > > > > Hmm it worries me a bit that we aren't passing it to linker: > > might break some builds in case compiler has a working > > protector but linker doesn't. > > Given we both compile and link (in configure) with the > same $compiler binary, this seems vanishingly unlikely. True - I really meant libtool but we don't test it ATM so we can leave that for another day. OK fair enough: Reviewed-by: Michael S. Tsirkin <mst@redhat.com> > > configure: check -c each time we run compiler > > > > Some warnings/errors only surface if you run compiler > > without a linker. Run both on each test. > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > > > > > diff --git a/configure b/configure > > index eb0e7bb..8adc72b 100755 > > --- a/configure > > +++ b/configure > > @@ -102,6 +102,7 @@ compile_object() { > > compile_prog() { > > local_cflags="$1" > > local_ldflags="$2" > > + do_cc $QEMU_CFLAGS -c $local_cflags -o $TMPO $TMPC > > do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags > > } > > > > That's a lot of extra compiles and configure isn't > exactly a speed demon as it is... > > thanks > -- PMM
On 10 April 2014 18:51, Michael S. Tsirkin <mst@redhat.com> wrote:
> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Thanks; patch applied to master.
-- PMM
diff --git a/configure b/configure index eb0e7bb..8adc72b 100755 --- a/configure +++ b/configure @@ -102,6 +102,7 @@ compile_object() { compile_prog() { local_cflags="$1" local_ldflags="$2" + do_cc $QEMU_CFLAGS -c $local_cflags -o $TMPO $TMPC do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags }