On Tue, 3 Aug 2021 at 09:30, Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > On Tue, Aug 3, 2021 at 12:55 AM Peter Maydell <peter.mayd...@linaro.org> > wrote: >> This one is still here: >> >> subprojects/libslirp/libslirp.so.0.3.1.p/src_arp_table.c.o: In >> function `arp_table_add': >> /mnt/nvmedisk/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:51: >> undefined reference to `__ubsan_handle_type_mismatch_v1' >> /mnt/nvmedisk/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:51: >> undefined reference to `__ubsan_handle_type_mismatch_v1' >> >> when building the subprojects/libslirp/libslirp.so.0.3.1 >> >> configure options: >> '../../configure' '--cc=clang' '--cxx=clang++' '--enable-gtk' >> '--extra-cflags=-fsanitize=undefined -fno-sanitize=shift-base >> -Werror' > > > I am not able to reproduce. Could you check the value of default_library for > libslirp when you run "meson configure". It should be "static".
I never run "meson configure". I just run the QEMU "make". Are you testing by starting with a before-the-libslirp-merge change QEMU, doing a build, then updating to the libslirp changes, and then doing a 'make' without reconfigure or 'make clean' ? I suspect this is perhaps to do with it being an incremental build. >> This happens because (as noted in the clang documentation for the >> sanitizer: https://clang.llvm.org/docs/AddressSanitizer.html) >> when linking a shared library with the sanitizers, clang does not >> link in the sanitizer runtime library. That library is linked in >> with the executable, and the shared library's references to the >> sanitizer runtime functions are satisfied that way. However >> you/meson are building libslirp.so with -Wl,--no-undefined >> so the link of the .so fails. >> (This does not happen with gcc, because gcc chose to make the >> default for sanitizers to be to link against a shared libasan, >> not a static one, the reverse of clang's default.) >> >> What I don't understand is why we're building the .so at all. >> I just tried a fresh build with >> '../../configure' '--cc=clang' '--cxx=clang++' '--enable-gtk' >> '--enable-sanitizers' >> to check that telling configure (and possibly thus meson) about >> the sanitizers more directly still demonstrated the problem: >> but that sidesteps it because it never builds the .so. >> My other build directories (the ones that do plain old gcc >> builds with no sanitizer) seem to have built the .so file >> as well, though, so this isn't related to either clang or to >> the sanitizers -- meson just doesn't seem to be consistent >> about what we build. >> >> A related meson bug: >> https://github.com/mesonbuild/meson/issues/764 >> (which was closed by just making meson warn if you tell it >> to both use --no-undefined (which is the default) and to use >> the sanitizer.) >> >> The ideal fix seems to me to be to figure out why we're >> building the libslirp .so and not do that. >> >> A simple fix/workaround would be to set "b_lundef = false" in >> default_options in your meson.build (which will suppress the >> -Wl,--no-undefined option). That does mean you won't get >> any warnings if you accidentally make libslirp use a function >> that is provided by the QEMU executable, I suppose. >> > > What if you pass --extra-ldflags='-fsanitize=undefined' then? -fsanitize=undefined is already in the ldflags. That doesn't help because clang is still going to decide not to statically link libasan and give an error because of -Wl,--noundefined. -- PMM