On 2023/04/23 19:28, Michael Tokarev wrote:
20.04.2023 08:29, Akihiko Odaki wrote:
On 2023/04/19 16:32, Michael Tokarev wrote:
Hello!
Today I discovered an interesting issue here: I copied a
system-installed
binary into another directory, in order to debug an unrelated issue.
Just
to discover it does not work, being unable to find any modules or data
files.
Here's how the strace of typical qemu-system-i386 run looks like (the
relevant parts only):
access("/tmp/qemu-bundle", R_OK) = -1 ENOENT (No such file or directory)
access("/tmp/b/../lib/x86_64-linux-gnu/qemu/accel-tcg-i386.so", F_OK)
= -1 ENOENT (No such file or directory)
access("/var/run/qemu/Debian_1_8.0~rc4+dfsg-3/accel-tcg-i386.so",
F_OK) = -1 ENOENT (No such file or directory)
(the executable in this case is in /tmp, obviously). And it fails with
error "fatal: could not load module for type 'tcg-accel-ops'".
This is despite the fact that qemu has been configured with proper
--libdir
and other --foodir to point to actual dirs such as /usr/lib
/usr/share etc.
Some files in QEMU installation is closely coupled with the binary so
it does not make much sense to copy only the executable to another
directory. You need to copy all of the files QEMU owns to relocate a
QEMU installation. QEMU uses relative paths to find such relocated files.
That said, it is indeed confusing that QEMU uses relative paths even
if you specify an absolute path for --libdir. I prefer to require to
specify relative paths for --libdir and other options to make a QEMU
installation relocatable, but I didn't dare making such a breaking
change.
Well, quite often it makes little sense still.
For example, in debian we had to (temporarily) move qemu-system-i386 from
/usr/bin/ to /usr/libexec/, replacing the /usr/bin/ one with a shell
wrapper
(to decouple xen hvm build out of main qemu build). It was just by a chance
the directory nesting is the same still, - I wanted to move it to
/usr/lib/qemu/
instead. But at least this one still works. Ditto for the actual xen
version,
the binary is in /usr/libexec/qemu-system-i386-xen now, I was about to
move it
to /usr/libexec/xen/qemu-system-i386 instead.
I see absolutely no reason for the binary to look into
/usr/libexec/share/qemu/bios.bin
if it is told to get all data files from /usr/share/qemu/.
What about specifying --bindir=/usr/libexec/xen?
Quite often I debug issues and have to compare "old" qemu with current one
(exactly like I did in this case), extracting the old binary into /tmp/.
And wonder why it breaks in other ways.
And I still don't see how this turning absolute paths into relative
(behind the
scenes) can be useful. If we put qemu into /usr/local/bin for example, it
can be configured to look for data files in /usr/local/share just fine,
there's no need for this "magic". On the other hand, if we really want
to use a different data dir, we can pass a right -L option.
As you say, data files are not tightly coupled with QEMU version and it
is quite possible to run QEMU with data files from another QEMU version.
However it's not true for all files QEMU installs. Especially module
files like accel-tcg-i386.so are tightly coupled with the executable and
QEMU is not expected to work if the exact modules which came with the
executable are not provided.
I think I'll just remove this (very questionable) behavior at least from
the
Debian package. I already patched out the previous version of this, when
it looked at ${exe_path}/../pc-bios - this at least made sense when we
needed to find firmware files for just-built qemu, in the source dir. But
it makes no sense (in my opinion) to do that for the installed version.
It uses qemu-bundle directory for just-built QEMU so it does not matter
for the scenario.
The scenario where this conversion for relative path makes sense is the
case you need to compare the behavior of two packaged versions of QEMU,
for example. In such case, you can extract each package into a different
directory and run them. Each QEMU executable will use relative paths to
find modules tied with it.
If you are removing this behavior from Debian package you may consult
other package maintainers, especially GCC package maintainers. If I
remember correctly, GCC also has similar logic to find executables like
cc1 and shared objects like LTO plugins.
Regards,
Akihiko Odaki
Thanks,
/mjt
