similar to: Re: Build failure of libnbd

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 libguestfs.org/libnbd > write of Go pointer 0xc000016060 to non-Go memory 0x7f5fe8297390 >

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

I took the easy route of crippling what I couldn't get working, on the grounds that partial coverage is better than none now that we have Cirrus CI checking commits on additional platforms. This series got me to a green checkmark: https://gitlab.com/ebblake/nbdkit/-/pipelines/793156983 but depends on an as-yet uncommitted patch in libvirt-ci:

Hi, I'm hitting that issue since Mesa 20.0.6 and it is present still in latest version 20.1.7 ``` [tkloczko at barrel SPECS]$ coredumpctl gdb 3926866 PID: 3926866 (test_va_api) UID: 1000 (tkloczko) GID: 1000 (tkloczko) Signal: 11 (SEGV) Timestamp: Sun 2020-09-13 18:57:06 BST (32s ago) Command Line: ./test_va_api Executable:

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 2: https://www.redhat.com/archives/libguestfs/2020-April/thread.html#00166 Version 3 contains all changes discussed in the previous review. Rich.

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:

On Tue Nov 25 2014 at 18:30:08 Carlo Alberto Ferraris <cafxx at strayorange.com> wrote: > Just curious: are you considering the possibility of enabling LTO across > user and runtime code? > Since AFAIK the product of go build is almost always a statically-linked > executable, I guess it would make sense (when doing an optimised build) to > feed the runtime to the linker in IR

Hi all, I'd like to propose the contribution of a Go frontend subproject to the LLVM project, based on the existing llgo project at https://github.com/go-llvm/llgo . As with the previous contribution of the Go bindings, I have obtained permission from all llgo contributors whose code is part of this contribution, to contribute their changes to the LLVM project and relicense their changes

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 Thu, Nov 20, 2014 at 12:19:06AM +0100, Joerg Sonnenberger wrote: > On Wed, Nov 19, 2014 at 01:53:17PM -0800, Peter Collingbourne wrote: > > llgo depends on certain third-party components, namely a copy of the Go > > standard library (libgo), a Go program analysis library (go.tools) and two > > library dependencies of the standard library (libbacktrace and libffi). >

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

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.

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

This feature is roughly finished now, although it needs a few more tests and some examples. It's pretty much up to par with all the other bindings, but it lacks a completely safe AIO buffer. It won't stop you from freeing the buffer too early) because golang's GC inexplicably lacks a way to declare a root from C. I can probably do it with a global variable and ref counting on the

Now runs a complete set of tests, notably including the AIO test. File descriptors are passed in and out as plain ints (instead of *os.File) for a couple of reasons: (1) We have to pass the plain int to syscall.Select. (2) Turning an fd into an os.File causes golang to set the blocking flag which is deeply unhelpful. Rich.

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

--- configure.ac | 2 +- golang/Makefile.am | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4e2bc65..9abec95 100644 --- a/configure.ac +++ b/configure.ac @@ -1530,7 +1530,7 @@ AS_IF([test "x$enable_golang" != "xno"],[ AC_CHECK_PROG([GOLANG],[go],[go],[no]) AS_IF([test "x$GOLANG" !=

Go 1.17 or newer is required to use unsafe.Slice(), which in turn allows us to write a simpler conversion from a C array to a Go object during callbacks. To check if this makes sense, look at https://repology.org/project/go/versions compared to our list in ci/manifest.yml, at the time I made this commit: Alpine 3.15: 1.17.10 AlmaLinux 8: 1.19.10 CentOS Stream 8: 1.20.4 Debian 10: 1.11.6 Debian

Hello. I'm very happy with libguestfs, but now i'm try to write packer plugin to strip images: 1) resize filesystem to minimum 2) resize partitions to minimum 3) create/resize file with needed size But golang binding have not docs. Is that possible to generate something suitable to godoc.org to determine api methods and input,output variables for functions? -- Vasiliy Tolstov, e-mail: