| Message ID | CAAu8pHu1gRD3MLP1wfHDmwjQJxHAacUqo_DtaKrMnC5iKO7+Fg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 4 August 2012 18:57, Blue Swirl <blauwirbel@gmail.com> wrote: > On Sat, Jul 28, 2012 at 1:48 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 28 July 2012 13:31, Blue Swirl <blauwirbel@gmail.com> wrote: >>> I'm getting this error, probably because now Valgrind support is enabled: >>> CC coroutine-ucontext.o >>> cc1: warnings being treated as errors >>> /src/qemu/coroutine-ucontext.c:204: error: unknown option after >>> '#pragma GCC diagnostic' kind >>> /src/qemu/coroutine-ucontext.c:209: error: unknown option after >>> '#pragma GCC diagnostic' kind >>> >>> Maybe the compiler does not understand this pragma and Valgrind check >>> should also fail in that case. >> >> Yeah, I think this is one of the few tests which want to explicitly >> check "is this construct going to provoke a compiler warning" -- >> fix is for that test to explictly put -Werror in the cflags in >> the compile_prog line. > > Now with your Xen configure patches in place, I'm not getting errors > with this applied except for Clang (which I didn't test earlier). > Maybe this should be applied. Yes, I think that (assuming we are going to go down this route at all) it would be good to apply this 11/11 patch now in good time before the freeze. Does anybody want to object? thanks -- PMM
On Thu, Aug 9, 2012 at 6:24 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 4 August 2012 18:57, Blue Swirl <blauwirbel@gmail.com> wrote: >> On Sat, Jul 28, 2012 at 1:48 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 28 July 2012 13:31, Blue Swirl <blauwirbel@gmail.com> wrote: >>>> I'm getting this error, probably because now Valgrind support is enabled: >>>> CC coroutine-ucontext.o >>>> cc1: warnings being treated as errors >>>> /src/qemu/coroutine-ucontext.c:204: error: unknown option after >>>> '#pragma GCC diagnostic' kind >>>> /src/qemu/coroutine-ucontext.c:209: error: unknown option after >>>> '#pragma GCC diagnostic' kind >>>> >>>> Maybe the compiler does not understand this pragma and Valgrind check >>>> should also fail in that case. >>> >>> Yeah, I think this is one of the few tests which want to explicitly >>> check "is this construct going to provoke a compiler warning" -- >>> fix is for that test to explictly put -Werror in the cflags in >>> the compile_prog line. >> >> Now with your Xen configure patches in place, I'm not getting errors >> with this applied except for Clang (which I didn't test earlier). >> Maybe this should be applied. > > Yes, I think that (assuming we are going to go down this route at all) > it would be good to apply this 11/11 patch now in good time before > the freeze. Does anybody want to object? I'll send a patch that fixes configure with Clang. > > thanks > -- PMM
diff --git a/configure b/configure index d8ec050..eb2ed2f 100755 --- a/configure +++ b/configure @@ -46,11 +46,11 @@ do_cc() { esac echo $cc -Werror "$@" >> config.log $cc -Werror "$@" >> config.log 2>&1 && return $? - echo "ERROR: configure test passed without -Werror but failed with -Werror." - echo "This is probably a bug in the configure script. The failing command" - echo "will be at the bottom of config.log." - echo "You can run configure with --disable-werror to bypass this check." - exit 1 + echo "ERROR: configure test passed without -Werror but failed with -Werror." >> config.log + echo "This is probably a bug in the configure script. The failing command" >> config.log + echo "will be at the bottom of config.log." >> config.log + echo "You can run configure with --disable-werror to bypass this check." >> config.log