Re: What is the correct way to add linker dependency to QEMU build system?

[Paz Offer]

...after some testing...

[Trying to add 'libdl' to be linked with QEMU]

I did try to use 'g_module_open/close/symbol', but what I noticed is that 'g_module_close' did not really unload my library.

So if I would do:

1. g_module_open(my-lib)
2. Load symbols, use my library...
3. g_module_close(my-lib)
4. Make modifications to my library and reload it:
5. g_module_open(my-lib)

Then the library was not really reloaded, and the old instance would still be used.

This did not happen when I used dlopen/dlclose.

Do we have a way to force 'g_module_close' to unload the library?

Thanks, Paz

---

From: Peter Maydell <peter.maydell@linaro.org>
Sent: Thursday, February 29, 2024 7:34 PM
To: Paz Offer <poffer@nvidia.com>
Cc: qemu-devel@nongnu.org <qemu-devel@nongnu.org>
Subject: Re: What is the correct way to add linker dependency to QEMU build system?

 

External email: Use caution opening links or attachments


On Thu, 29 Feb 2024 at 16:10, Paz Offer <poffer@nvidia.com> wrote:
> I want to add library 'libdl' to be linked with QEMU build for a particular target (e.g. - qemu-system-arm).
> Using meson I would typically do 'compiler.find_library(...)', and later add the returned dependency to the binary dependencies list.
> However, in QEMU I understand that these configurations are done in the './configure' file?
>
> What would be the correct way to do this?

If you can do the job using the glib g_module_open()/
g_module_symbol() functions (which is how QEMU itself does
loading of plugin and module DLLs, and which on Unix hosts
are pretty much wrappers around dlopen/dlsym) then you
don't need to link against libdl at all.

If this is for something you're planning to upstream
then it might be worth talking at a higher level about
what you're aiming to do. (If it's for something downstream
that you don't plan to ever upstream then you can do
whatever's easiest for you, of course.)

-- PMM