Re: get_relocated_path: the configured paths are not looked for?

[Michael Tokarev]

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/.

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.

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.

Thanks,

/mjt