Thanks for the reply! After recompiling gcc-go and libgo with the " -Wa,-momit-lock-prefix=yes -march=i586" flags and compiling hugo with:
go build -gccgoflags="-Wa,-momit-lock-prefix=yes -march=i586" Still getting an error, but a more terse version: ./hugo panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0xc pc=0xb768bdf2] goroutine 1 [running]: The same executable still works on my VM (although blows up with more than 1 core on the VM, as one might expect) Any more pointers? This is just a play project, if it doesn't work it's not the end of the world. On Thu, 15 Apr 2021 at 22:20, Ian Lance Taylor <[email protected]> wrote: > On Thu, Apr 15, 2021 at 1:11 PM David Markey <[email protected]> wrote: > > > > I'm trying to get hugo to work on my Alpine distro that's running on my > Intel gallileo(Quark CPU). > > > > I've overcome a few hurdles already. > > > > This CPU Doesn't have MMX so gcc-go was needed to compile hugo into a > binary (in a virtual machine) > > > > But after copying the hugo binary to the galileo Hugo doesn't work. I > get the following error: > > > > fatal error: unexpected signal during runtime execution [signal SIGSEGV: > segmentation violation code=0x1 addr=0x44 pc=0xb7658e62] goroutine 1 > [running]: runtime.dopanic_m :0 runtime.throw :0 runtime.sigpanic :0 > runtime.sigtrampgo :0 runtime.sigtramp :0 :0 goroutine 4 [select]: > go.x2eopencensus.x2eio..z2fstats..z2fview.worker.start > /root/go/pkg/mod/[email protected]/stats/view/worker.go:154 > created by > go.x2eopencensus.x2eio..z2fstats..z2fview.go.x2eopencensus.x2eio..z2fstats..z2fview..init0 > /root/go/pkg/mod/[email protected]/stats/view/worker.go:32 +0x17a > > > > This could be: > > > > Galileo has 256MB of ram only, The executable is 127MB, perhaps there > simply isn't enough memory? > > This particular error looks like a nil dereference. That would only > be caused by insufficient memory if the Go code calls C code that > calls malloc and doesn't check for a return value of NULL. > > > > Quark has a well known bug. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575%22 that means it > mishandles LOCK instructions and causes a segfault. > > > > On a normal C toolchain, the assembler can strip the LOCK operation > using "-Xassembler '-momit-lock-prefix=yes'" CFLAG (Galileo is single core > so it's not needed) > > > > However I'm not sure what the equivalent would be on a go build > toolchain, perhaps it's simply not possible? > > Since you are using gccgo, the same option should work. But you might > possibly have to recompile the Go library with that option. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANXrN%3D2ZZ599pZWKGS%2B0wU0WWftcjmpN36-2jB5oeV-GATjTYg%40mail.gmail.com.
