Hi Peter

On Tue, Jun 1, 2021 at 1:17 PM Peter Maydell <peter.maydell@linaro.org> wrote:
On Sat, 29 May 2021 at 19:55, <marcandre.lureau@redhat.com> wrote:
>
> From: Marc-André Lureau <marcandre.lureau@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:
>
>   git@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.

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" ?

Running configure before make should also prevent this from happening.


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.

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?
 
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

--
Marc-André Lureau