path: root/results/classifier/zero-shot/118/unknown/1701798

architecture: 0.857
permissions: 0.854
performance: 0.843
register: 0.831
device: 0.831
files: 0.827
peripherals: 0.809
virtual: 0.808
user-level: 0.808
arm: 0.796
assembly: 0.793
graphic: 0.793
network: 0.792
debug: 0.788
socket: 0.781
KVM: 0.776
PID: 0.769
VMM: 0.765
boot: 0.755
risc-v: 0.747
vnc: 0.745
hypervisor: 0.742
semantic: 0.739
kernel: 0.735
i386: 0.733
mistranslation: 0.715
ppc: 0.703
TCG: 0.699
x86: 0.670

dynamically linked binaries crash for big-endian targets

On the targets
  hppa
  m68k
  mips
  mips64
  powerpc
  powerpc64
  s390x
  sparc64
dynamically linked binaries crash, but statically linked binaries work.
On the targets
  aarch64
  alpha
  armhf
  powerpc64le
  sh4
both dynamically linked and statically linked binaries work.

How to reproduce:

1) On Ubuntu 16.04, install the packages
g++-5-aarch64-linux-gnu
g++-5-alpha-linux-gnu
g++-5-arm-linux-gnueabihf
g++-5-hppa-linux-gnu
g++-5-m68k-linux-gnu
g++-5-mips-linux-gnu
g++-5-mips64-linux-gnuabi64
g++-5-powerpc-linux-gnu
g++-5-powerpc64-linux-gnu
g++-5-powerpc64le-linux-gnu
g++-5-s390x-linux-gnu
g++-5-sh4-linux-gnu
g++-5-sparc64-linux-gnu

2) Install qemu 2.9.0 from source (for m68k, use the 2.7.0-m68k
code from https://github.com/vivier/qemu-m68k.git):
$ ../configure --prefix=/home/bruno/inst-qemu/2.9.0 --target-list=aarch64-softmmu,alpha-softmmu,arm-softmmu,i386-softmmu,m68k-softmmu,mips-softmmu,mipsel-softmmu,mips64-softmmu,mips64el-softmmu,ppc-softmmu,ppc64-softmmu,s390x-softmmu,sh4-softmmu,sparc-softmmu,sparc64-softmmu,x86_64-softmmu,aarch64-linux-user,alpha-linux-user,arm-linux-user,hppa-linux-user,m68k-linux-user,mips-linux-user,mipsel-linux-user,mips64-linux-user,mips64el-linux-user,ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,s390x-linux-user,sh4-linux-user,sparc-linux-user,sparc64-linux-user --disable-strip --disable-werror --enable-gtk --enable-vnc
$ make
$ make install

3) Cross-compile the programs:

$ aarch64-linux-gnu-gcc-5 -O hello.c -o hello.aarch64
$ alpha-linux-gnu-gcc-5 -O hello.c -o hello.alpha
$ arm-linux-gnueabihf-gcc-5 -O hello.c -o hello.armhf
$ hppa-linux-gnu-gcc-5 -O hello.c -o hello.hppa
$ m68k-linux-gnu-gcc-5 -O hello.c -o hello.m68k
$ mips-linux-gnu-gcc-5 -O hello.c -o hello.mips
$ mips64-linux-gnuabi64-gcc-5 -O hello.c -o hello.mips64
$ powerpc-linux-gnu-gcc-5 -O hello.c -o hello.powerpc
$ powerpc64-linux-gnu-gcc-5 -O hello.c -o hello.powerpc64
$ powerpc64le-linux-gnu-gcc-5 -O hello.c -o hello.powerpc64le
$ s390x-linux-gnu-gcc-5 -O hello.c -o hello.s390x
$ sh4-linux-gnu-gcc-5 -O hello.c -o hello.sh4
$ sparc64-linux-gnu-gcc-5 -O hello.c -o hello.sparc64

4) Run the programs:

* aarch64 works:
$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 hello.aarch64
Hello world

* alpha works:
$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-alpha hello.alpha 
Hello world

* armhf works:
$ QEMU_LD_PREFIX=/usr/arm-linux-gnueabihf ~/inst-qemu/2.9.0/bin/qemu-arm hello.armhf
Hello world

* powerpc64le works:
$ QEMU_LD_PREFIX=/usr/powerpc64le-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64le hello.powerpc64le
Hello world

* sh4 works:
$ QEMU_LD_PREFIX=/usr/sh4-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sh4 hello.sh4
Hello world

* ===== sparc64 does not work:
$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sparc64 hello.sparc64
Segmentation fault (core dumped)

When I copy the file to a machine with `uname -srm` = "Linux 4.5.0-2-sparc64 sparc64",
it works:
$ ./hello.sparc64
Hello world

When I copy the file and its execution environment /usr/sparc64-linux-gnu to the
same machine and run the binary in a chroot environment:
# /bin/hello.sparc64 
Hello world

* ===== mips does not work:
$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-mips hello.mips
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-4kc-malta mips",
it works:
$ ./hello.mips
Hello world

When I copy the file and its execution environment /usr/mips-linux-gnu to the
same machine and run the binary in a chroot environment:
# /bin/hello.mips 
Hello world

* ===== mips64 does not work:
$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.9.0/bin/qemu-mips64 hello.mips64
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-5kc-malta mips64",
it works:
$ ./hello.mips64
Hello world

* ===== powerpc does not work:
$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc hello.powerpc
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

When I copy the file to a machine with `uname -srm` = "Linux 3.17.2-200.fc20.ppc64p7 ppc64",
it works:
$ ./hello.powerpc
Hello world

* ===== powerpc64 does not work:
$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64 hello.powerpc64
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

When I copy the file to a machine with `uname -srm` = "Linux 3.17.2-200.fc20.ppc64p7 ppc64",
it works:
$ ./hello.powerpc64
Hello world

* ===== s390x does not work:
$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-s390x hello.s390x
<hangs>
$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.8.1/bin/qemu-s390x hello.s390x
qemu-s390x: /media/develdata/devel/build/qemu-2.8.1/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed.
Segmentation fault (core dumped)

When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-s390x s390x",
it works:
$ ./hello.s390x
Hello world

* ===== hppa does not work:
$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-hppa hello.hppa
Segmentation fault (core dumped)

* ===== m68k does not work:
$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.9.0/bin/qemu-m68k hello.m68k
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.7.0-m68k/bin/qemu-m68k hello.m68k
qemu: uncaught target signal 11 (Segmentation fault) - core dumped


The set of targets where it does not work is exactly the big-endian targets.

I would guess that the problem comes from a missing (or an extra) BSWAP call in one of the files
  include/elf.h
  include/hw/elf_ops.h
  linux-user/elfload.c


I think I hit this problem trying to use qemu-s390x-static in the s390x/ubuntu:16.04 docker image. Running qemu-s390x-static 2.9.0 on binaries in that image (e.g. /bin/echo) results in a hang.

I've noticed that doing the same in a s390x/debian:jessie image does NOT have the same problem. No hang. Looks like the binaries are built for different kernel versions, could that be why?

$ file ubuntu16.04/bin/echo
ubuntu16.04/bin/echo: ELF 64-bit MSB shared object, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=4befa0df07957e117e8cc44d0dd14a3df6d44619, stripped

$ file debian/bin/echo
debian/bin/echo: ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 2.6.32, BuildID[sha1]=4bd45eb0ae5287ba9271a9daa9809166dd2eeab5, stripped

The behaviour in qemu-2.10 is nearly the same as in qemu-2.9. The only difference is a different kind of crash for m68k:

$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.9.0/bin/qemu-m68k hello.m68k
qemu: uncaught target signal 4 (Illegal instruction) - core dumped

$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10.0/bin/qemu-m68k hello.m68k
qemu: uncaught target signal 11 (Segmentation fault) - core dumped


Can you check whether these work if you copy the QEMU and the dynamically linked target binary into a chroot (which does not have the x86 host ld.so or /etc in it) instead of using QEMU_LD_PREFIX ? There is a problem I've seen before where:
 1) QEMU when run with QEMU_LD_PREFIX or -L works by "first try in -L, then try in the host filesystem"
 2) files like /etc/ld.so.cache (and other things the dynamic linker uses) are not in the -L directory but are in the host
 3) the ld.so.cache format is not endian-agnostic
 4) glibc's dynamic linker code does not ignore a wrong-endian ld.so.cache but crashes instead

Using a chroot instead of QEMU_LD_PREFIX will work as a test of whether this is the kind of problem you're running into. Personally I think that (4) is a glibc bug...


For s390x, the hang definitely still occurs using a chroot with qemu-s390x-static copied in and no QEMU_LD_PREFIX. I'm not in a good position to test other big-endian architectures though.

I just tested with powerpc and current head-of-git QEMU and it works:

e104462:xenial:bug-1701798$ cat hello.c
#include <stdio.h>
int main(void) {
    printf("hello world\n");
    return 0;
}
e104462:xenial:bug-1701798$ powerpc-linux-gnu-gcc-5 -O hello.c -o hello.powerpc
e104462:xenial:bug-1701798$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/linaro/qemu-from-laptop/qemu/build/all-linux-static/ppc-linux-user/qemu-ppc ./hello.powerpc 
hello world

Similarly mips, sparc64, powerpc64, hppa, mips64 are fine.

m68k is known to be not working for real m68k currently (it's mostly a coldfire target), so not surprising that that doesn't work.

s390x still crashes:
qemu-s390x: /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/translate-all.c:189: tb_lock: Assertion `!have_tb_lock' failed.

So either we've fixed a bug here, or the problem is in your environment.

For s390, it looks like the guest is trying to use an insn we don't implement:
#0  0x0000000060215018 in raise ()
#1  0x000000006021573a in abort ()
#2  0x0000000060079a96 in op_risbg (s=0x7fffffffda10, o=0x7fffffffd950)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:3450
#3  0x0000000060082c8b in translate_one (env=0x627f0350, s=0x7fffffffda10)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:5824
#4  0x0000000060082f3f in gen_intermediate_code (cs=0x627e80b0, 
    tb=0x60794d40 <static_code_gen_buffer+56064>)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:5925
#5  0x00000000600369aa in tb_gen_code (cpu=0x627e80b0, pc=274886359240, 
    cs_base=0, flags=3, cflags=0)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/translate-all.c:1286
#6  0x00000000600343ff in tb_find (cpu=0x627e80b0, 
    last_tb=0x60794c00 <static_code_gen_buffer+55744>, tb_exit=0, cf_mask=0)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:402
#7  0x0000000060034b36 in cpu_exec (cpu=0x627e80b0)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:722
#8  0x000000006003ac78 in cpu_loop (env=0x627f0350)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:3255
---Type <return> to continue, or q <return> to quit---
#9  0x000000006003c68c in main (argc=2, argv=0x7fffffffe458, envp=0x7fffffffe470)
    at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:4882

where the abort is in op_risbg() because s->fields->op2 is 0x59, which we don't handle.

We then fail to correctly report that abort(), because linux-user has never been very good with reporting signals caused by QEMU itself -- it assumes signals including SIGABRT are due to the guest code and tries to deliver them as guest signals, usually tripping itself up in the process. We then run into the bug described in https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg01506.html which is why we get the have_tb_lock assertion.



This patch fixes the s390 issue:
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01103.html

which is the only part of this (ignoring m68k) that I could reproduce. Bruno: can you still reproduce any of the other problems with a new QEMU?


> can you still reproduce any of the other problems with a new QEMU?

On the same system (Ubuntu 16.04 x86_64, not a chroot environment), I still observe the same symptoms with QEMU as of today than with 2.9.0 or 2.10.0:

$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sparc64 hello.sparc64
Segmentation fault (core dumped)
$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-sparc64 hello.sparc64
Segmentation fault (core dumped)

$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-mips hello.mips
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-mips hello.mips
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.9.0/bin/qemu-mips64 hello.mips64
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.10+-20171107/bin/qemu-mips64 hello.mips64
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc hello.powerpc
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc hello.powerpc
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64 hello.powerpc64
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc64 hello.powerpc64
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-s390x hello.s390x
Killed
$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-s390x hello.s390x
Killed

$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-hppa hello.hppa
Segmentation fault (core dumped)
$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-hppa hello.hppa
Segmentation fault (core dumped)

$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10.0/bin/qemu-m68k hello.m68k
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10+-20171107/bin/qemu-m68k hello.m68k
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)


Re #4:
>  2) files like /etc/ld.so.cache (and other things the dynamic linker uses) are not in the -L directory but are in the host
>  3) the ld.so.cache format is not endian-agnostic
>  4) glibc's dynamic linker code does not ignore a wrong-endian ld.so.cache but crashes instead

Indeed the problem is with /etc/ld.so.cache, and ONLY /etc/ld.so.cache. When I hack the do_openat function in linux-user/syscall.c, to pretend that no /etc/ld.so.cache exists, - see attached hide-ld.so.cache.diff - the dynamically-linked binaries work (except the s390x case, which you identified as a different issue):

$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-sparc64 hello.sparc64
Hello world
$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-mips hello.mips
Hello world
$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.10+-20171107/bin/qemu-mips64 hello.mips64
Hello world
$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc hello.powerpc
Hello world
$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc64 hello.powerpc64
Hello world
$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-s390x hello.s390x
Killed
$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-hppa hello.hppa
Hello world
$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10+-20171107/bin/qemu-m68k hello.m68k
Hello world

Hurray! This bug that has seriously limited the value of linux-user emulation is now gone for me!

> Can you check whether these work if you copy the QEMU and the dynamically linked target binary into a chroot

This is way too cumbersome for me:
  - Need to copy my workspaces into specific file locations on the disk,
  - Need to use 'chroot' command before anything else,
  - Need to use a statically-linked qemu.

> Personally I think that (4) is a glibc bug...

Maybe, but if you can fix it in 5 to 10 lines code in qemu, I doubt it's worth reporting it to the glibc people.

Small improvement: In my hack, I just pretended /etc/ld.so.cache is absent. Possibly it's better to map it to $QEMU_LD_PREFIX/etc/ld.so.cache .

That patch would prevent us from picking up a legitimate ld.so.cache for the guest (in a chroot, for instance), so I don't think we should take it. (I'm also not a fan of trying to work around specific guest code issues: I'd much rather this was just fixed in ld.so where it ought to be, so I'd encourage you to report it to the glibc folks.)

You can probably also work around this by creating an empty ld.so.cache in the QEMU_LD_PREFIX directory, though it's awkward if you wanted that to be the /usr/whatever directory.

The underlying problem here is that the -L option is not really a very good one compared to a proper chroot -- it doesn't really present a proper guest filesystem to the guest.


> That patch would prevent us from picking up a legitimate ld.so.cache for the guest (in a chroot, for instance), so I don't think we should take it.
But in a chroot, QEMU_LD_PREFIX is most likely NOT set. So how about this pseudocode?

  if (strcmp (pathname, "/etc/ld.so.cache") == 0 && getenv ("QEMU_LD_PREFIX") != NULL) {
    pathname = concat (getenv ("QEMU_LD_PREFIX"), pathname);
  }

That is, redirect /etc/ld.so.cache to $QEMU_LD_PREFIX/etc/ld.so.cache if and only if $QEMU_LD_PREFIX is set.

> You can probably also work around this by creating an empty ld.so.cache in the QEMU_LD_PREFIX directory, though it's awkward if you wanted that to be the /usr/whatever directory.

Indeed, qemu already analyzes the QEMU_LD_PREFIX, stores a cache of its contents in the static variable 'base', and uses it in the do_openat() function.

The following provides a workaround for me that does not require any change to qemu:

sudo mkdir -p $QEMU_LD_PREFIX/etc
sudo ln -s /nonexistent $QEMU_LD_PREFIX/etc/ld.so.cache


I still feel we shouldn't be working around guest code bugs in QEMU, so I'm not sure there's anything more for QEMU to do here. You should report the dynamic linker bug to glibc upstream.


My feeling is that glibc upstream will not want to care about cross qemu situations. I would prefer to report it to the Ubuntu cross-tools maintainers: The package libc6-<cpu>-cross contains the file /usr/<cpu>-linux-gnu/lib/libc.so.6; they could surely add the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache as well.

I believe this same bug affects me on Linux Mint 18.3 Sylvia which is based on Ubuntu Xenial.
The suggestion from #12 helped me. Thank you @bruno-clisp!

Did we open a precise glibc upstream bug for this so I can go upvote it? :-)

Workaround from #12 also worked for me. 

Tested on Buildroot with this precise setup: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/e855a262fd872171156894e9045814cb0f346dab#stack-smashing-detected

For Google, the error message in that setup is:

*** stack smashing detected ***: <unknown> terminated
qemu: uncaught target signal 6 (Aborted) - core dumped

but must be the same as reported here just with a different glibc setup leading to slightly different crash.


The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.

If you still think this bug report here is valid, then please switch
the state back to "New" within the next 60 days, otherwise this report
will be marked as "Expired". Or please mark it as "Fix Released" if
the problem has been solved with a newer version of QEMU already.

Thank you and sorry for the inconvenience.


The issue seems to be fixed, even without the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache.
For m68k: since version 2.10.0.
For s390x: since version 2.11.0.
For the other platforms, already since 2.9.0 (strange, this contradicts my original report...).

My last comment ("The issue seems to be fixed, even without the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache.") was incorrect. When this symlink is set, the program accesses /etc/ld.so.cache after accessing /usr/<cpu>-linux-gnu/etc/ld.so.cache. In some cases, it works, in some cases it doesn't — depending on the contents of /etc/ld.so.cache.

The better fix is to replace /usr/<cpu>-linux-gnu/etc/ld.so.cache with an empty file:

rm -f "/usr/<cpu>-linux-gnu/etc/ld.so.cache"
mkdir -p "/usr/<cpu>-linux-gnu/etc"
: > "/usr/<cpu>-linux-gnu/etc/ld.so.cache"