On Sat, Aug 8, 2015 at 12:22 AM, Ted Unangst <[email protected]> wrote: Thanks everyone to your follow-ups.
> talk to upstream? this sounds like a bug if the runtime detection is > insufficient. >From what I gathered about Go so far, upstream had already fixed that (see references in my previous posts). The problem might be more subtle, as I am "cross-"building the Go package on a SSE machine, but then install and run it on a non-SSE machine. At build time, the Go system will correctly detect my build host's capabilities, which results in Go system binaries that include SSE instructions. However, these system binaries fail with SIGILL on my non-SSE target as the initial Go loader, linker and other Go system libraries (try to) use SSE instructions at startup time of the Go system, before it actually detects the less capable CPU of my run-time target host. Thus my hypothesis is that the Go package would run fine if I would build it directly on the non-SSE target. But currently, I have no build environment on a ALIX host. Still, I will dig a bit further into the implementation of the Go system while learning it, and while experimenting with gopacket and its sub-libraries such as the recent bsdbpf. > unconditionally disabling sse would be a pessimization for most > users. As I share your concern, I thought that a separate flavour might be a solution. Another much more pragmatic and lighther solutions would be to just add a short note (in the Makefile or package info?) that shows how to rebuild the package for those who want to run Go on non-SSE CPU like Geode LX on ALIX.
