On Tue, Mar 24, 2020 at 02:16:32PM -0500, Eric Blake wrote:> On 3/24/20 1:54 PM, Richard W.M. Jones wrote: > >On Tue, Mar 24, 2020 at 01:43:52PM -0500, Eric Blake wrote: > >>On 3/21/20 7:06 AM, Richard W.M. Jones wrote: > >>>Eric: > >>> > >>>Yifan Gu has posted a few patches for mingw support. My comments > >>>below. > >>> > >>>https://github.com/gyf304/nbdkit/commit/a37c4ca6546dfc4e96e305af97b62e5a9d6174ca > >>> > >>>* I think the SHARED_LDFLAGS idea is good. I pushed a slightly > >>> different take on the idea here: > >>> https://github.com/libguestfs/nbdkit/commit/1d634009ab8e43592065ec469df6312400525cc8 > >>> It's slightly different from what Yifan posted above, because I > >>> replaced -module -avoid-version -shared with $(SHARED_LDFLAGS), > >>> adding -no-undefined additionally on mingw. > >> > >>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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
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
I see. That makes sense.
On 3/24/20 3:12 PM, Eric Blake wrote:>> (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)?I guess what I haven't said yet is that the existing proposed patches from Frank for making mingw compile are NOT the right way to resolve the need for -no-undefined on that platform. Instead of creating lots of wrapper functions buried inside #ifdef WINDOWS_COMPAT, we really should be focusing on creating a clean libnbdkit.so/dll library that exposes all of the needed symbols without the need for preprocessor magic, and therefore without API breaks. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org