On Tue, 1 Jun 2021 at 12:01, Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > > Hi Peter > > On Tue, Jun 1, 2021 at 1:17 PM Peter Maydell <peter.mayd...@linaro.org> wrote: >> >> On Sat, 29 May 2021 at 19:55, <marcandre.lur...@redhat.com> wrote: >> > >> > From: Marc-André Lureau <marcandre.lur...@redhat.com> >> > >> > The following changes since commit >> > 62c0ac5041e9130b041adfa13a41583d3c3ddd24: >> > >> > Merge remote-tracking branch 'remotes/rth-gitlab/tags/pull-tcg-20210526' >> > into staging (2021-05-28 16:25:21 +0100) >> > >> > are available in the Git repository at: >> > >> > g...@github.com:elmarco/qemu.git tags/libslirp-pull-request >> > >> > for you to fetch changes up to b060428091c758781acc4d42849accc036d3c816: >> > >> > build-sys: make libslirp a meson subproject (2021-05-29 22:52:37 +0400) >> > >> > ---------------------------------------------------------------- >> > Update libslirp & make it a subproject >> > >> > ---------------------------------------------------------------- >> >> All hosts, odd warnings on checkout and running configure: >> >> warning: unable to rmdir 'slirp': Directory not empty > > > This one is from git itself. It doesn't clean up old submodule locations, > even though they are actually "clean". git submodule "(re)move" has its > limits I guess.
Yeah, I guess we have to live with this one. >> make: Entering directory '/home/pm/qemu/build/all' >> config-host.mak is out-of-date, running configure >> GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 >> tests/fp/berkeley-softfloat-3 dtc capstone slirp >> warn: ignoring non-existent submodule slirp > > > However, I don't get this when simply running make. Maybe you run make in > parallel, and config-host.mak didn't have the time to regenerate with a new > GIT_SUBMODULES. > > I wonder if we miss a dependency like "git-submodule-update: config-host.mak" > ? Something looks like it's still using an old list of submodules. > Running configure before make should also prevent this from happening. Incremental build needs to keep working. >> >> BSD VMs: error message just before launching the VM (though the VM did >> seem to then launch OK): >> >> Found ninja-1.8.2 at /usr/bin/ninja >> ninja: no work to do. >> (GIT="git" "/home/peter.maydell/qemu-netbsd/scripts/git-submodule.sh" >> update ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/be >> rkeley-softfloat-3 dtc capstone slirp) >> warn: ignoring non-existent submodule slirp >> /usr/bin/python3 -B /home/peter.maydell/qemu-netbsd/tests/vm/netbsd >> --debug --jobs 8 --verbose --image >> "/home/peter.maydell/.cache/qemu >> -vm/images/netbsd.img" --snapshot --build-qemu >> /home/peter.maydell/qemu-netbsd -- >> DEBUG:root:Creating archive >> /home/peter.maydell/qemu-netbsd/build/vm-test-6kefrq76.tmp/data-f706c.tar >> for src_dir dir: /home/peter.maydell/q >> emu-netbsd >> error: pathspec 'slirp' did not match any file(s) known to git. Maybe this is something needing updating in the "create the archive" script? >> >> clang sanitizer build: link failure: >> subprojects/libslirp/libslirp.so.0.3.0.p/src_arp_table.c.o: In >> function `arp_table_add': >> /home/petmay01/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:51: >> undefined reference to `__ubsan_handle_type_mismatch_v1' >> /home/petmay01/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:51: >> undefined reference to `__ubsan_handle_type_mismatch_v1' >> /home/petmay01/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:51: >> undefined reference to `__ubsan_handle_type_mismatch_v1' >> /home/petmay01/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:34: >> undefined reference to `__ubsan_handle_type_mismatch_v1' >> /home/petmay01/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:34: >> undefined reference to `__ubsan_handle_type_mismatch_v1' >> (and lots more similar) > I don't get this when running make vm-build-netbsd. What else am I missing? This isn't NetBSD related, it's just a clang sanitizer build on Linux. >> OSX: linker warnings linking libslirp.0.dylib: >> >> >> [34/1977] Linking target subprojects/libslirp/libslirp.0.dylib >> ld: warning: dylib >> (/usr/local/Cellar/glib/2.68.0/lib/libgthread-2.0.dylib) was built for >> newer macOS version (10.15) than being linked (10.4) >> ld: warning: dylib >> (/usr/local/Cellar/glib/2.68.0/lib/libglib-2.0.dylib) was built for >> newer macOS version (10.15) than being linked (10.4) >> ld: warning: dylib (/usr/local/opt/gettext/lib/libintl.dylib) was >> built for newer macOS version (10.14) than being linked (10.4) >> > > This looks related to: > https://gitlab.freedesktop.org/slirp/libslirp/-/commit/410e296a52fb274648f8ecf53561eaab4b33c52c > > It could be that we need to use the version information from glib (or from > any libraries used). > > It looks safe to ignore although I re-opened: > https://gitlab.freedesktop.org/slirp/libslirp/-/issues/36#note_940695 I'm not generally a fan of ignoring warnings. I would prefer it if we understood why it was happening and how shared libraries are supposed to be being built. thanks -- PMM