[Libguestfs] nbdkit / mingw support

Eric Blake eblake at redhat.com
Tue Mar 24 20:12:19 UTC 2020


On 3/24/20 2:44 PM, Richard W.M. Jones wrote:

>>>> Why are we trying to avoid -no-undefined on other platforms?
>>>
>>> Isn't it because we rely on it, since our plugins need symbols that
>>> are undefined at link time such as nbdkit_*?
>>
>> Yes, at the moment they do, but do they need to? We could ship
>> libnbdkit which provides just the symbols that plugins can link
>> against, and then link our binary nbdkit against that same library,
>> rather than expecting our plugins to compile undefined until loaded
>> by our binary.  In other words, if the fix is by separating our
>> public functions into a shared library for mingw to compile plugins
>> without undefined symbols, why not do the same for all platforms?
> 
> (For non-mingw platforms) this breaks the source API promises rather
> seriously, so if I understand your proposal correctly I don't think
> this is a good idea.  It's possibly something we can consider for
> internal plugins, or for the V3 API.

How does it break API to request that someone link against a particular 
library if they want to avoid undefined symbols (and to continue to 
allow the to link with undefined symbols if they choose not to compile 
against that library)?

That is, I'm trying to see what you are considering to be a break between:

- what we have now:
nbdkit-file-plugin.so: depends on nbdkit_realpath() as undefined symbol
nbdkit binary: provides nbdkit_realpath() before dlloading the plugin

- building with -no-undefined
libnbdkit.so: provides nbdkit_realpath()
nbdkit binary: depends on libnbdkit.so, making nbdkit_realpath() available
nbdkit-file-plugin.so: depends on libnbdkit.so, so it sees nbdkit_realpath()

- out-of-tree with undefined symbol
libnbdkit.so: provides nbdkit_realpath()
nbdkit binary: depends on libnbdkit.so, making nbdkit_realpath() available
nbdkit-file-plugin.so: undefined dependency on nbdkit_realpath()

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




More information about the Libguestfs mailing list