[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 2/4] configure: introduce --extra-libs

From: Peter Maydell
Subject: Re: [Qemu-devel] [RFC PATCH 2/4] configure: introduce --extra-libs
Date: Mon, 25 Jan 2016 17:36:36 +0000

On 25 January 2016 at 17:25, Alex Bennée <address@hidden> wrote:
> Well LDFLAGS doesn't get applied everywhere so with:
> --cc=gcc-5 --cxx=g++-5 --extra-cflags="-fsanitize=thread"
>   --extra-ldflags="-ltsan" --with-coroutine=gthread
> You get compile failures in the ancillary binaries that are used during
> testing.
>   LINK  tests/qemu-iotests/socket_scm_helper
> tests/qemu-iotests/socket_scm_helper.o: In function `main':
> /home/alex/lsrc/qemu/qemu.git/tests/qemu-iotests/socket_scm_helper.c:95: 
> undefined reference to `__tsan_func_entry'
> /home/alex/lsrc/qemu/qemu.git/tests/qemu-iotests/socket_scm_helper.c:106: 
> undefined reference to `__tsan_read8'
> /home/alex/lsrc/qemu/qemu.git/tests/qemu-iotests/socket_scm_helper.c:106: 
> undefined reference to `__tsan_read8'
> ...

That seems like a bug -- we should be applying LDFLAGS there
I think. (Consider that we put things like -g and -m32 there.)

> I think this stems from my confusion from exactly which binaries are
> meant to be affected by which flags. QEMU_CFLAGS seems to imply it's
> QEMU only, but we don't have a QEMU_LDFLAGS so should LDFLAGS be shared
> with all binaries we build?

Back in 2012 and commit caa50971f2e the distinction was apparently
that QEMU_CFLAGS was for flags without which QEMU can't compile,
whereas CFLAGS was for flags like "-g -O2" which the user can
safely override. This may even still be true :-)

Given that I suspect the reason we don't have a QEMU_LDFLAGS is
that users are less in the habit of trying to run make with a
hand-specified CFLAGS.

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]