user --static builds are apparently resulting in dynamically linked
executables (to the glibc library, not other shared objects )
Concise summary:
$ file ../qemu-aarch64_v*
../qemu-aarch64_v4.2.1: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), statically linked,
BuildID[sha1]=70f5e10ac0eb9b63d7758850e2f18d0a047d4b79, for GNU/Linux
3.2.0, with debug_info, not stripped
../qemu-aarch64_v5.2: ELF 64-bit LSB shared object, x86-64, version 1
(GNU/Linux), dynamically linked,
BuildID[sha1]=91fda2fa08f46d1bb6d19b6f72a4819a7c20fd7e, for GNU/Linux
3.2.0, stripped
$ ldd ../qemu-aarch64_v*
../qemu-aarch64_v4.2.1:
not a dynamic executable
../qemu-aarch64_v5.2:
statically linked
Between v4.2.1 and HEAD and (trying to) perform git-bisect builds using:
$ ../../qemu/configure --disable-system --enable-linux-user --static
--target-list=aarch64-linux-user
All builds from v5.x onwards report:
$ file qemu-aarch64
qemu-aarch64: ELF 64-bit LSB shared object, x86-64, version 1
(GNU/Linux), dynamically linked,
BuildID[sha1]=546ba11f0de940f7f3cbfaffae3c2bb54b683386, for GNU/Linux
3.2.0, with debug_info, not stripped
Whereas builds of v4.2.1 report:
$ file ./aarch64-linux-user/qemu-aarch64
./aarch64-linux-user/qemu-aarch64: ELF 64-bit LSB executable, x86-64,
version 1 (GNU/Linux), statically linked,
BuildID[sha1]=70f5e10ac0eb9b63d7758850e2f18d0a047d4b79, for GNU/Linux
3.2.0, with debug_info, not stripped
... the same as the v4.2.0 built by Debian/Ubuntu:
$ file /usr/bin/qemu-aarch64-static
/usr/bin/qemu-aarch64-static: ELF 64-bit LSB executable, x86-64, version
1 (GNU/Linux), statically linked,
BuildID[sha1]=abad039a2cfc5bc87215554230a572b085fbc37a, for GNU/Linux
3.2.0, with debug_info, not stripped
This could be a problem because when the executable is dynamically
linked to glibc the same glibc version needs to be installed in the
chroot and that isn't always possible.
I'm unsure whether this is a cosmetic issue of file/ldd reporting or is
a regression.
Hit this whilst in the process of trying to isolate commits that fixed
another issue where using qemu-aarch64 on x86_64 Debian/Ubuntu host with
a foreign architecture chroot that results in "handle_cpu_signal
received signal outside vCPU context" when doing "chroot
debian-buster-aarch64 aptitude full-upgrade".
