Re: [Libguestfs] Build failure of libnbd
[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 ../../../libgo/runtime/proc.c:593 Notice that these two packages both provide /usr/bin/go, using alternatives: $ rpm -qf /usr/bin/go golang-bin-1.15.3-1.fc34.x86_64 gcc-go-10.2.1-5.fc34.x86_64 $ ll /usr/bin/go lrwxrwxrwx. 1 root root 20 Oct 15 12:46 /usr/bin/go -> /etc/alternatives/go So the easy fix is to remove gcc-go from your Dockerfile. However I will take a look at why gcc-go doesn't work, as I guess we ought to try to support both, or if gcc-go cannot work then we ought to reject it in ./configure. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
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 fatal error: Go pointer stored into non-Go memory
runtime stack: runtime_mstart ../../../libgo/runtime/proc.c:593
Notice that these two packages both provide /usr/bin/go, using alternatives:
$ rpm -qf /usr/bin/go golang-bin-1.15.3-1.fc34.x86_64 gcc-go-10.2.1-5.fc34.x86_64 $ ll /usr/bin/go lrwxrwxrwx. 1 root root 20 Oct 15 12:46 /usr/bin/go -> /etc/alternatives/go
So the easy fix is to remove gcc-go from your Dockerfile.
However I will take a look at why gcc-go doesn't work, as I guess we ought to try to support both, or if gcc-go cannot work then we ought to reject it in ./configure.
nbdkit-golang-plugin also fails to build with gcc-go: cd examples/disk && \ PKG_CONFIG_PATH="/home/rjones/d/nbdkit/server/local${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}" \ GOPATH="/home/rjones/d/nbdkit/plugins/golang" \ go build -o nbdkit-godisk-plugin.so -buildmode=c-shared # _/home/rjones/d/nbdkit/plugins/golang/examples/disk /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/10/libgolibbegin.a(libgolibbegin_a-go-libmain.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /usr/bin/ld: /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Even adding -pthread didn't help here. I guess gcc-go is just broken. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
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 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 ../../../libgo/runtime/proc.c:593
Notice that these two packages both provide /usr/bin/go, using alternatives:
$ rpm -qf /usr/bin/go golang-bin-1.15.3-1.fc34.x86_64 gcc-go-10.2.1-5.fc34.x86_64 $ ll /usr/bin/go lrwxrwxrwx. 1 root root 20 Oct 15 12:46 /usr/bin/go -> /etc/alternatives/go
So the easy fix is to remove gcc-go from your Dockerfile.
However I will take a look at why gcc-go doesn't work, as I guess we ought to try to support both, or if gcc-go cannot work then we ought to reject it in ./configure.
nbdkit-golang-plugin also fails to build with gcc-go:
cd examples/disk && \ PKG_CONFIG_PATH="/home/rjones/d/nbdkit/server/local${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}" \ GOPATH="/home/rjones/d/nbdkit/plugins/golang" \ go build -o nbdkit-godisk-plugin.so -buildmode=c-shared # _/home/rjones/d/nbdkit/plugins/golang/examples/disk /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/10/libgolibbegin.a(libgolibbegin_a-go-libmain.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /usr/bin/ld: /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status
Even adding -pthread didn't help here. I guess gcc-go is just broken.
Could be, thanks a lot for figuring it out, I hope the time is not wasted and it at least helps someone somewhere... at some point. The list of packages is something I will have to go through anyway, for not it is just a list taken from libvirt CI container with bunch of things added for libnbd. The ultimate goal with this is to have automatically updated repository like libnbd-go that looks exactly how golang developers want it so that they can consume it the usual way and it should also be properly tagged whenever a tag is updated in the upstream repository. The fact that there are some checks shouldn't hurt, right? ;-)
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On Sat, Oct 17, 2020 at 10:48:13PM +0200, Martin Kletzander wrote:
The list of packages is something I will have to go through anyway, for not it is just a list taken from libvirt CI container with bunch of things added for libnbd.
Ideally it should be driven from ”dnf builddep libnbd”, directly or indirectly. For golang ...
The ultimate goal with this is to have automatically updated repository like libnbd-go that looks exactly how golang developers want it so that they can consume it the usual way and it should also be properly tagged whenever a tag is updated in the upstream repository. The fact that there are some checks shouldn't hurt, right? ;-)
... we would have to add golang as an extra dep since we don't build it in Fedora. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Sat, Oct 17, 2020 at 10:08:26PM +0100, Richard W.M. Jones wrote:
On Sat, Oct 17, 2020 at 10:48:13PM +0200, Martin Kletzander wrote:
The list of packages is something I will have to go through anyway, for not it is just a list taken from libvirt CI container with bunch of things added for libnbd.
Ideally it should be driven from ”dnf builddep libnbd”, directly or indirectly. For golang ...
Well, I was aiming for upstream, not just Fedora. Also that would not work when you add a new dependency. I think of CI as something that should strive to work and not take any extra time once it is properly set up. But who knows, maybe I won't finish it.
The ultimate goal with this is to have automatically updated repository like libnbd-go that looks exactly how golang developers want it so that they can consume it the usual way and it should also be properly tagged whenever a tag is updated in the upstream repository. The fact that there are some checks shouldn't hurt, right? ;-)
... we would have to add golang as an extra dep since we don't build it in Fedora.
Again, upstream, plus the fact that testing less than what's possible is undesirable in my opinion as it defeats the purpose of CI, especially when it does not really that any extra effort.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Sun, Oct 18, 2020 at 12:03:36AM +0200, Martin Kletzander wrote:
On Sat, Oct 17, 2020 at 10:08:26PM +0100, Richard W.M. Jones wrote:
On Sat, Oct 17, 2020 at 10:48:13PM +0200, Martin Kletzander wrote:
The list of packages is something I will have to go through anyway, for not it is just a list taken from libvirt CI container with bunch of things added for libnbd.
Ideally it should be driven from ”dnf builddep libnbd”, directly or indirectly. For golang ...
Well, I was aiming for upstream, not just Fedora. Also that would not work when you add a new dependency. I think of CI as something that should strive to work and not take any extra time once it is properly set up. But who knows, maybe I won't finish it.
I see - sounds like we need a machine-readable cross-distro way to describe dependencies. Ideally in groups, like "minimal" dependencies, "test only", "maximum features" etc. We could even translate these automatically or semi-automatically into spec files, debian directory etc. This would be nice to have but I'm not aware of a way to do this. Didn't Andrea describe something like this recently? 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 Sun, Oct 18, 2020 at 01:36:03PM +0100, Richard W.M. Jones wrote:
On Sun, Oct 18, 2020 at 12:03:36AM +0200, Martin Kletzander wrote:
On Sat, Oct 17, 2020 at 10:08:26PM +0100, Richard W.M. Jones wrote:
On Sat, Oct 17, 2020 at 10:48:13PM +0200, Martin Kletzander wrote:
The list of packages is something I will have to go through anyway, for not it is just a list taken from libvirt CI container with bunch of things added for libnbd.
Ideally it should be driven from ”dnf builddep libnbd”, directly or indirectly. For golang ...
Well, I was aiming for upstream, not just Fedora. Also that would not work when you add a new dependency. I think of CI as something that should strive to work and not take any extra time once it is properly set up. But who knows, maybe I won't finish it.
I see - sounds like we need a machine-readable cross-distro way to describe dependencies. Ideally in groups, like "minimal" dependencies, "test only", "maximum features" etc. We could even translate these automatically or semi-automatically into spec files, debian directory etc. This would be nice to have but I'm not aware of a way to do this. Didn't Andrea describe something like this recently?
Yes, they are listed in a file and there is a mapping. Sure, ideally we would plug this into the libvirt-ci machinery, but unfortunately for starters that has become too big of a hammer for this kind of nail. Also it works nicely when it is done on GitLab as GitHub has a different way of running their own CI. However first I need to make sure that this is something worth investing in after I try to deploy the auto-update of libnbd-go. We can also expand it onto all libguestfs repos, but that's a long way ahead of us.
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
participants (2)
-
Martin Kletzander -
Richard W.M. Jones