Re: [Libguestfs] nbdkit / mingw support
On 3/24/20 2:18 PM, Frank Gu wrote:
[top-posting on technical lists makes it harder to follow the
conversation; I'm reordering your mail]
On Tue, Mar 24, 2020 at 15:16 Eric Blake <eblake(a)redhat.com>
wrote:
>> 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?
I think that will break the ABI backward compatibility.
How does it break ABI compatibility? An old plugin that was compiled on
Linux with undefined symbols will still have those symbols satisfied at
load-time by nbdkit, since nbdkit itself depends on libnbdkit to pull in
those symbols. And while we would change in-tree plugins to use
-no-undefined (which means in-tree plugins link against libnbdkit), it
doesn't force out-of-tree plugins to compile against the library
(out-of-tree plugins are not required to use libtool), so out-of-tree
plugins can still have the same ABI compatibility as what we guarantee
for plugins compiled against older nbdkit versions.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org