search for: lnbdkit

On 8/18/20 5:50 AM, Richard W.M. Jones wrote: > --- > +++ b/configure.ac > @@ -457,11 +457,13 @@ AS_CASE([$host_os], > [mingw*|msys*|cygwin*], [ > is_windows=yes > NO_UNDEFINED_ON_WINDOWS="-no-undefined" > + LINK_LIBNBDKIT_ON_WINDOWS='$(top_builddir)/server/libnbdkit.la' Cygwin supports linking with undefined symbols, but it

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 still work, so it wouldn't be > a source API break. Yes, that's what I'm thinking - it's an API break i...

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 then it would still work, so it wouldn't be > >a source API break. > > Yes, that's what I'm thinking - i...

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

...hich 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 months ago to move only a bare minimum into a library. > > Note this change is backwards compatible. Because the rump nbdkit > binary links with -lnbdkit it...

...not the installed nbdkit. > > + > > +case "$1" in > > + --cflags*) echo "-I@abs_top_builddir@/include" ;; > > + *) ;; > > +esac > > Don't you need something like this too: > > --libs) echo "-L@abs_top_builddir@/lib -lnbdkit" We don't actually have "libnbdkit". It was proposed a while back but we didn't get sufficient review feedback, and the code was very complex and unmaintainable so it never made it upstream. cgo currently issues the following two commands: $PKG_CONFIG --cflags -- nbdkit...

...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 links with -lnbdkit it still contains and reexports all the symbols, so plugins and filters which don't explicitly link with -lnbdkit will still be loadabl...

When compiling when an older nbdkit is installed, the build would fail because certain symbols such as .get_ready were not defined: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) This happens because we were using the installed <nbdkit-plugin.h> rather than the local copy. We don't want

--- configure.ac | 2 ++ filters/blocksize/Makefile.am | 1 + filters/cache/Makefile.am | 1 + filters/cacheextents/Makefile.am | 1 + filters/cow/Makefile.am | 1 + filters/ddrescue/Makefile.am | 1 + filters/delay/Makefile.am | 3 +++ filters/error/Makefile.am | 1 + filters/exitlast/Makefile.am | 3 +++

This is an incomplete port to Windows. Currently the server compiles and starts up successfully, but goes into an infinite loop when you connect to it. Nevertheless I think the approach is ready for feedback. This being Windows the changes go quite deep. Rich.

...d relative to the local > +# directory and not the installed nbdkit. > + > +case "$1" in > + --cflags*) echo "-I@abs_top_builddir@/include" ;; > + *) ;; > +esac Don't you need something like this too: --libs) echo "-L@abs_top_builddir@/lib -lnbdkit" The installed nbdkit.pc would do this I presume. Or are you happy relying on the allow undefined symbols LDFLAGS Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :|...

...gt; > > +case "$1" in > > > + --cflags*) echo "-I@abs_top_builddir@/include" ;; > > > + *) ;; > > > +esac > > > > Don't you need something like this too: > > > > --libs) echo "-L@abs_top_builddir@/lib -lnbdkit" > > We don't actually have "libnbdkit". It was proposed a while back but > we didn't get sufficient review feedback, and the code was very > complex and unmaintainable so it never made it upstream. Ah I see then. > cgo currently issues the following two co...

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 still work, so it wouldn't be a source API break. I had a look into how we might implement libnbdkit.so. Some functions are obv...

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

...0b17ef95..61ee3a02 100644 --- a/configure.ac +++ b/configure.ac @@ -489,12 +489,18 @@ AS_CASE([$host_os], LIBS="$LIBS -lmsvcrt -lkernel32 -luser32" NO_UNDEFINED_ON_WINDOWS="-no-undefined" IMPORT_LIBRARY_ON_WINDOWS='-Wl,-L$(top_builddir)/server -Wl,-lnbdkit' + SOEXT="dll" ], - [is_windows=no] + [is_windows=no], [ + SOEXT="so" + ] ) AC_MSG_RESULT([$is_windows]) AC_SUBST([NO_UNDEFINED_ON_WINDOWS]) AC_SUBST([IMPORT_LIBRARY_ON_WINDOWS]) +AC_SUBST([SOEXT]) +AC_DEFINE_UNQUOTED([SOEXT],["$SOEXT&quo...

The patches following do indeed allow you to compile nbdkit.exe, but it does not actually work yet. I'm posting this experimental series more as a work in progress and to get feedback. Note this does not require Windows itself to build or test. You can cross-compile it using mingw64-* packages on Fedora or Debian, and test it [spoiler alert: it fails] using Wine. Rich.

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw This is the port to Windows using native Windows APIs (not MSYS or Cygwin). This patch series is at the point where it basically now works. I can run the server with the memory plugin, and access it remotely using guestfish, creating filesystems and so on without any apparent problems. Nevertheless there are many

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 randomly unless I revert this patch. I didn't investigate this yet so it

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw-nolib After a lot of work I have made the port to Windows work without using a separate library. Instead, on Windows only, we build an "import library" (library of stubs) which resolves references to nbdkit_* functions in the main program and fixes up the plugin, basically the first technique outlined in