similar to: [PATCH nbdkit v3 0/2] golang: Compile against the local nbdkit build.

On 4/23/20 2:13 PM, Richard W.M. Jones wrote: > Compiling nbdkit from source when an older nbdkit is installed would > fail because certain symbols such as .get_ready are not defined in the > (installed) <nbdkit-plugin.h>: > > ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) >

Version 1 was here: https://www.redhat.com/archives/libguestfs/2020-April/thread.html#00160 Version 2 side-steps the objections to the first patch by using a well-formed alternate nbdkit.pc file and running ordinary pkg-config against it, so any parsing of --cflags etc will be done by pkg-config. The first patch is essentially the same idea as:

Compiling nbdkit from source when an older nbdkit is installed would fail because certain symbols such as .get_ready are not defined in the (installed) <nbdkit-plugin.h>: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) Of course we should be compiling against the local include/nbdkit-plugin.h

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

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

Sorry Dan, but I really do dislike golang with a passion :-) Here is a patch that allows you to write nbdkit plugins in golang. As with C, OCaml and Rust, you can write a plugin in Go which compiles directly to a .so file that can be loaded into golang, so in that sense it works completely differently from scripting language plugins like Perl and Python where there's an

[Adding libguestfs mailing list] I reproduced it locally - the difference was installing "gcc-go". I only had golang-bin installed previously. With gcc-go installed: ../run go install libguestfs.org/libnbd write of Go pointer 0xc000016060 to non-Go memory 0x7f5fe8297390 fatal error: Go pointer stored into non-Go memory runtime stack: runtime_mstart

Thanks: Dan Berrangé XXX UNFINISHED: - Is using uintptr for the handle a good idea? Plugins must return something != 0. In other languages we would allow plugins to return an arbitrary object here, but this is not possible in golang because of lack of GC roots. - Default can_* methods are hard to implement. Ideally we would be able to test if a user plugin implements a

For the current set of examples this doesn't matter. This also adds another example where we use the Connection to store data, just to check that actually works. Thanks: James @ purpleidea, Dan Berrangé --- plugins/golang/nbdkit-golang-plugin.pod | 10 +- plugins/golang/Makefile.am | 9 + plugins/golang/examples/disk/disk.go | 168 ++++++++++++++++++

On Tue, Apr 21, 2020 at 05:07:43PM +0100, Daniel P. Berrangé wrote: > On Tue, Apr 21, 2020 at 11:44:59AM +0100, Richard W.M. Jones wrote: > > Thanks: Dan Berrangé > > > > XXX UNFINISHED: > > > > - Is using uintptr for the handle a good idea? Plugins must return > > something != 0. In other languages we would allow plugins to > > return an

On Thu, Apr 23, 2020 at 05:58:25PM +0100, Daniel P. Berrangé wrote: > On Thu, Apr 23, 2020 at 05:55:14PM +0100, Richard W.M. Jones wrote: > > 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

--- run.in | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/run.in b/run.in index 8fdf454..438a68c 100755 --- a/run.in +++ b/run.in @@ -140,15 +140,15 @@ export PERL_VALGRIND=1 export PERL_DESTRUCT_LEVEL=2 # For Python. -export PYTHON=@PYTHON@ +export PYTHON="@PYTHON@" prepend PYTHONPATH "$b/python/.libs" prepend PYTHONPATH

Another test, the same as before.

Best of .. 4?

After enabling procmail debugging ...

This is a repost so I can test my procmail script / automatic testing framework. The patch series is identical to v1. Rich.

Patch 1 cleans up the gobject tests. Patches 2 and 3 remote gtk-doc, which is slow and useless, and replace it with a simple manual page. https://bugzilla.redhat.com/show_bug.cgi?id=1465665 Rich.

Similar to C, OCaml and Rust, this is not a plugin per se. Instead it's more of a method and set of tests around writing plugins in golang. They are standalone programs that compile into shared objects that nbdkit can then load (so there is no "go plugin" between nbdkit and the user plugin, unlike in scripting languages like Perl). --- plugins/golang/nbdkit-golang-plugin.pod

These bindings get as far as running very simple connections. However there are many missing parts still: * No callbacks. * No functions which handle buffers (pread/pwrite!) This is posted just for general early interest, not even for review. Rich.

On Sat, Oct 17, 2020 at 09:00:30AM +0100, Richard W.M. Jones wrote: >On Sat, Oct 17, 2020 at 08:48:40AM +0100, Richard W.M. Jones wrote: >> [Adding libguestfs mailing list] >> >> I reproduced it locally - the difference was installing "gcc-go". >> I only had golang-bin installed previously. With gcc-go installed: >> >> ../run go install