On 25 January 2016 at 17:25, Alex Bennée <[email protected]> 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. thanks -- PMM
