On 2023/04/23 22:22, Michael Tokarev wrote:
23.04.2023 14:47, Akihiko Odaki пишет:
https://salsa.debian.org/qemu-team/qemu/-/commit/e017f53a8550d0bcaaca81c6dacac8ec34295cf0
fwiw.
I seriously think you better consult GCC and other package maintainers
to have consensus on handling this kind of scenario. Otherwise you don't
get the behavior you expect from other packages.
Also, that works only if the version changed. For example, consider
the case where you patched a module downstream. To compare the
behaviors of the patched and unpatched ones, you'll need to copy the
modules somewhere else.
Let's focus on modules in this discussion. There should be no problem
with data files here. You can pick data files from a different QEMU
version and it should just work fine. And even if it unfortunately
does not work, you can still use -L option to fix it.
That's not the case for modules. Modules are coupled with the
executable so you need to copy them along with the executable and the
executable should be able to find them.
The modules case is actually trivial. For this one, we have
$QEMU_MODULE_DIR which, if set, will be searched first.
There's no need to make tricks and turn --libdir or --datadir
specified at configure time as absolute paths, into something
entirely unpredictable.
/mjt
It is more preferable to use modules which are bundled with the
executable by default since they are coupled with the executable and you
should never want to use alternative modules unless you are debugging
QEMU. The current logic can reliably find the modules if either relative
paths or absolute paths of the executable and modules are preserved.
That said, it's very reasonable to specify absolute paths to --libdir
when you want to relocate only the executable (e.g. moving
bin/qemu-system-i386 into libexec/xen/qemu-system-i386) but keep other
files in the configured path, and the current QEMU build scripts do not
allow that. If you explain a convincing reason for doing that, I think
there is a good chance to get a patch to cover such a case merged.
But of course that is something a maintainer decides and I'm not
responsible here. util/cutils.c has no maintainer listed and the last
change made for get_relocated_path() was merged by Paolo Bonzini. He is
also a maintainer of the build infrastructure.
Regards,
Akihiko Odaki