Richard Henderson <richard.hender...@linaro.org> writes:
> On 9/4/23 08:00, Alex Bennée wrote: >> Due to the b4 dropping the vdso.so in the patch this fails: >> Program build-vdso.sh found: YES >> (/home/alex/lsrc/qemu.git/linux-user/build-vdso.sh) >> ../../linux-user/s390x/meson.build:24:0: ERROR: File vdso.so does not >> exist. >> A full log can be found at >> /home/alex/lsrc/qemu.git/builds/all/meson-logs/meson-log.txt >> FAILED: build.ninja >> /home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/meson --internal >> regenerate /home/alex/lsrc/qemu.git /home/alex/lsrc/qemu.git/builds/all >> ninja: error: rebuilding 'build.ninja': subcommand failed >> BUILD aarch64-softmmu guest-tests >> tests/tcg/aarch64-softmmu: -march=armv8.3-a detected >> which makes me think the dependencies are broken anyway because I >> have a >> working s390x compiler: >> ➜ cat tests/tcg/s390x-linux-user/config-target.mak >> # Automatically generated by configure - do not modify >> TARGET_NAME=s390x >> TARGET=s390x-linux-user >> EXTRA_CFLAGS= >> CC=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-gcc -i qemu/debian-s390x-cross -s /home/alex/lsrc/qemu.git -- >> CCAS=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-gcc -i qemu/debian-s390x-cross -s /home/alex/lsrc/qemu.git -- >> AR=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-ar -i qemu/debian-s390x-cross -s /home/alex/lsrc/qemu.git -- >> AS=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-as -i qemu/debian-s390x-cross -s /home/alex/lsrc/qemu.git -- >> LD=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-ld -i qemu/debian-s390x-cross -s /home/alex/lsrc/qemu.git -- >> NM=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-nm -i qemu/debian-s390x-cross -s /home/alex/lsrc/qemu.git -- >> OBJCOPY=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-objcopy -i qemu/debian-s390x-cross -s >> /home/alex/lsrc/qemu.git -- >> RANLIB=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-ranlib -i qemu/debian-s390x-cross -s >> /home/alex/lsrc/qemu.git -- >> STRIP=/home/alex/lsrc/qemu.git/builds/all/pyvenv/bin/python3 -B >> /home/alex/lsrc/qemu.git/tests/docker/docker.py --engine docker cc --cc >> s390x-linux-gnu-strip -i qemu/debian-s390x-cross -s /home/alex/lsrc/qemu.git >> -- >> BUILD_STATIC=y >> QEMU=/home/alex/lsrc/qemu.git/builds/all/qemu-s390x >> HOST_GDB_SUPPORTS_ARCH=y >> We really need to express the dependency on >> docker-image-debian-s390x-cross (when using containers) to ensure we can >> build the vdso.so and not rely on the copy we have. > > I think expressing the dependency is a mistake. > > The major problem is network unreliability. I installed a new vm to > build test this, and it took more than a dozen retrys to get all of > the docker images built. > > What we do right now is determine if docker or podman is present and > works, and then *assume* we can make all of the cross-compilers work > later, and so register them as cross-compilers early. Fair enough. I'm all for making the normal case easy, but then how do we express the explicit "please build the binary for me"? > > I think the only moderately reliable thing is to determine what > containers are already present and working and use only those. > Developers will need to manually rebuild containers periodically and > then re-run configure to make those visible to the cross-build > machinery. Not completely ideal, of course, but nothing else is > either. > > > r~ -- Alex Bennée Virtualisation Tech Lead @ Linaro
