search for: libnbdkit

...1 ++++++++++++++++++++++++++++++++++++++++++++++ > server/Makefile.am | 3 ++ > server/internal.h | 1 + > lib/lib.h | 48 +++++++++++++++++++++++++++++++ > lib/init.c | 53 ++++++++++++++++++++++++++++++++++ > wrapper.c | 18 ++++++++---- > lib/libnbdkit.syms | 47 ++++++++++++++++++++++++++++++ > 9 files changed, 237 insertions(+), 6 deletions(-) > > +++ b/lib/Makefile.am > @@ -0,0 +1,71 @@ > +EXTRA_DIST = libnbdkit.syms > + > +# Note this library always has soname “libnbdkit.so.0” because plugins > +# which may link to...

...nts.c | 4 +- > lib/parse.c | 341 +++++++++++++++++++++++++ > lib/password.c | 152 +++++++++++ > lib/path.c | 97 +++++++ > {server => lib}/test-public.c | 3 +- > .gitignore | 2 +- > lib/libnbdkit.syms | 20 ++ > 11 files changed, 645 insertions(+), 512 deletions(-) This one's still big, but not as daunting. Thanks for doing the split. > +++ b/server/public.c > @@ -36,7 +36,6 @@ > > #include <config.h> > > -#include <fcntl.h> >...

On 3/26/20 5:42 PM, Richard W.M. Jones wrote: > On Thu, Mar 26, 2020 at 04:35:29PM -0500, Eric Blake wrote: >> Should the test-public binary still be compiled from direct files >> under lib/, or should it be linked against libnbdkit.so? > > I will fix this in my copy. > >> I'm wondering if we want to add some sort of >> 'assert(is_initialized)' to all of our public entry functions to >> ensure that no one is actually trying to use libnbdkit.so without >> having first gone through...

...| 1 + lib/Makefile.am | 71 ++++++++++++++++++++++++++++++++++++++++++++++ server/Makefile.am | 3 ++ server/internal.h | 1 + lib/lib.h | 48 +++++++++++++++++++++++++++++++ lib/init.c | 53 ++++++++++++++++++++++++++++++++++ wrapper.c | 18 ++++++++---- lib/libnbdkit.syms | 47 ++++++++++++++++++++++++++++++ 9 files changed, 237 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index 92e0d4e3..bf720cec 100644 --- a/configure.ac +++ b/configure.ac @@ -1057,6 +1057,7 @@ AC_CONFIG_FILES([Makefile filters/truncate/Makefile...

On 3/25/20 7:16 AM, Richard W.M. Jones wrote: > I think I understand now that libnbdkit.so won't break the ABI for > existing plugins. Does it require that plugins for newer nbdkit use > -lnbdkit (which would be a source API break) or would it still be > possible to compile without this? I guess as long as plugins do not > start using -no-undefined then it would stil...

This is the previous 5/9 patch posted earlier today, split into reviewable chunks. This passes bisection with -x 'make && make check', but I didn't work very hard on the commit messages, so I refer you back to the original patch to explain how it works: https://www.redhat.com/archives/libguestfs/2020-March/msg00248.html Rich.

On Thu, Mar 26, 2020 at 04:35:29PM -0500, Eric Blake wrote: > Should the test-public binary still be compiled from direct files > under lib/, or should it be linked against libnbdkit.so? I will fix this in my copy. > I'm wondering if we want to add some sort of > 'assert(is_initialized)' to all of our public entry functions to > ensure that no one is actually trying to use libnbdkit.so without > having first gone through nbdkit_private_init;[...] So f...

...t allow shared libraries to contain any > undefined symbols. nbdkit previously relied on undefined symbols in > all plugins and filters (eg. nbdkit_parse_int) which get resolved at > run time by the nbdkit program. In order to make this work on Windows > we need to have a new library (libnbdkit.so on Linux, but probably > called something like LIBNBDKIT.DLL on Windows) which will contain > these symbols, and plugins can then be compiled with -lnbdkit so they > will link with this library, hence no undefined symbols. This is a lot nicer than the last attempt we made several month...

...; > >>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 s...

...ause Windows does not allow shared libraries to contain any undefined symbols. nbdkit previously relied on undefined symbols in all plugins and filters (eg. nbdkit_parse_int) which get resolved at run time by the nbdkit program. In order to make this work on Windows we need to have a new library (libnbdkit.so on Linux, but probably called something like LIBNBDKIT.DLL on Windows) which will contain these symbols, and plugins can then be compiled with -lnbdkit so they will link with this library, hence no undefined symbols. Note this change is backwards compatible. Because the rump nbdkit binary link...

...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 fu...

...o it is fine right here. Yup, better suggestions greatfully accepted, but I couldn't see anywhere obvious. Maybe internal.h? > >+ > >+int > >+main (int argc, char *argv[]) > >+{ > >+ /* This does nothing except call into the real main function in > >+ * libnbdkit.so. > >+ */ > >+ return nbdkit_main (argc, argv); > >+} > >diff --git a/server/nbdkit.syms b/server/nbdkit.syms > >index a67669b7..a516cc0f 100644 > >--- a/server/nbdkit.syms > >+++ b/server/nbdkit.syms > >@@ -54,6 +54,7 @@ > > nbdkit_ex...

On Wed, Mar 25, 2020 at 07:46:37AM -0500, Eric Blake wrote: > On 3/25/20 7:16 AM, Richard W.M. Jones wrote: > >I think I understand now that libnbdkit.so won't break the ABI for > >existing plugins. Does it require that plugins for newer nbdkit use > >-lnbdkit (which would be a source API break) or would it still be > >possible to compile without this? I guess as long as plugins do not > >start using -no-undefined th...

This creates libnbdkit.so as discussed in the following thread: https://www.redhat.com/archives/libguestfs/2020-March/thread.html#00203 test-delay-shutdown.sh fails for unclear reasons. This series starts by reverting "tests: Don't strand hung nbdkit processes" which is because several other tests fail ra...

I believe after a lot of reading around this topic that it should be possible to call from the plugin DLLs into functions in the EXE. One technique is outlined here: https://stackoverflow.com/a/18147774 The idea above is to use DLLTOOL to generate an "import library" (a static linked library containing stubs which are used to resolve at runtime a list of symbols). Import libraries

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

...++++++++++++++++++++++++++++ > 3 files changed, 134 insertions(+) > > diff --git a/tests/Makefile.am b/tests/Makefile.am > index f9c6b8ad..901dca7e 100644 > --- a/tests/Makefile.am > +# Build a plugin with libtool -undefined flag. This is how plugins > +# were built before libnbdkit.so existed. > +TESTS += \ > + test-undefined.sh \ > + $(NULL) > > +# For use of the -rpath option, see: > +# https://lists.gnu.org/archive/html/libtool/2007-07/msg00067.html > +test_undefined_plugin_la_LDFLAGS = \ > + -module -avoid-version -shared \ > + -undefined \ &gt...

...> > >> 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 s...

...server/main.c | 5 +++ server/nbdkit.syms | 5 --- server/plugins.c | 2 +- server/public.c | 21 +++---------- server/quit.c | 2 +- lib/lib.h | 15 +++++++++ lib/init.c | 15 +++++++++ lib/slow.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++ lib/libnbdkit.syms | 5 +++ 11 files changed, 132 insertions(+), 24 deletions(-) diff --git a/lib/Makefile.am b/lib/Makefile.am index 6826269b..4fca7c9d 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -48,6 +48,7 @@ libnbdkit_la_SOURCES = \ parse.c \ password.c \ path.c \ + slow.c \ vfprintf.c \...

...----------- {server => lib}/extents.c | 4 +- lib/parse.c | 341 +++++++++++++++++++++++++ lib/password.c | 152 +++++++++++ lib/path.c | 97 +++++++ {server => lib}/test-public.c | 3 +- .gitignore | 2 +- lib/libnbdkit.syms | 20 ++ 11 files changed, 645 insertions(+), 512 deletions(-) diff --git a/lib/Makefile.am b/lib/Makefile.am index 4896dc95..268282af 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -40,8 +40,12 @@ EXTRA_DIST = libnbdkit.syms lib_LTLIBRARIES = libnbdkit.la libnbdkit_la_...