Re: [Libguestfs] nbdkit / mingw support
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