[Libguestfs] nbdkit / mingw support

[Eric Blake]

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 at 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