Yes, new bug please, that's definitely a different symptom and likely an
unrelated issue.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1696353
Title:
golang binaries fail to start under linux-user
I just gave it a test with qemu-arm and Go binaries still crash for me,
albeit differently:
root@nofan:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@nofan:/# gccgo-7 hello.go -o hello
root@nofan:/# ./hello
mmap errno 9
fatal error: mmap
runtime
Since this has been fixed/worked around on the go side (thanks for
following up with that!) I'm going to close this as "wontfix" on QEMU's
side. It would be nice to support clone() with non-standard flags but
since we can't do that while we still link with libc there's no way we
can do this without
The go team have applied the above patch and I can confirm that it is
now working properly using go-tip. This means it will be fixed in go
1.10.
So if you recompile your go binary with go-tip or go 1.10 when it is
released, it will run fine under qemu-system-arm.
--
You received this bug notific
You can also apply this patch to go - I don't have an opinion on the
correct course of action though!
diff --git a/src/runtime/os_linux.go b/src/runtime/os_linux.go
index a6efc0e3d1..64218e3f7e 100644
--- a/src/runtime/os_linux.go
+++ b/src/runtime/os_linux.go
@@ -132,7 +132,8 @@ const (
Note that there is a go bug about this issue too:
https://github.com/golang/go/issues/20763
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1696353
Title:
golang binaries fail to start under linux-us
True, but it used to work albeit with slightly wrong semantics. It now
fails hard even though the golang runtime doesn't make any use of Sys V
semaphores so the presence of the flag is not noticeable by any normal
user.
--
You received this bug notification because you are a member of qemu-
devel
The problem with doing that is that it doesn't actually change the
behaviour. We use pthread_create to create the new thread, which glibc
does with a clone with CLONE_SYSVSEM set. We can't tell the difference
between "guest program needs the new threads to not share SysV semaphore
behaviour" and "g
