x/sys/unix: Does not build on mipsel/mips64el/alpha/powerpc with gccgo

[NightTsarina]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

• go version go1.6.1 gccgo (Debian 6.2.1-4) 6.2.1 20161119 linux/mipsn64
• go version go1.6.1 gccgo (Debian 6.2.1-4) 6.2.1 20161119 linux/mipso32

Same for alpha and powerpc (the 4 arches use gccgo in Debian).

What operating system and processor architecture are you using (go env)?

GOARCH="mipsn64"
GOHOSTARCH="mipsn64"
GOHOSTOS="linux"
GOOS="linux"

What did you do?

$ go build golang.org/x/sys/unix
# golang.org/x/sys/unix
obj-mips64el-linux-gnuabi64/src/golang.org/x/sys/unix/flock.go:15:30: error: reference to undefined name 'SYS_FCNTL'
 var fcntl64Syscall uintptr = SYS_FCNTL
                              ^
obj-mips64el-linux-gnuabi64/src/golang.org/x/sys/unix/sockcmsg_linux.go:15:30: error: reference to undefined name 'SizeofUcred'
  b := make([]byte, CmsgSpace(SizeofUcred))
                              ^
obj-mips64el-linux-gnuabi64/src/golang.org/x/sys/unix/sockcmsg_linux.go:16:9: error: reference to undefined name 'Cmsghdr'
  h := (*Cmsghdr)(unsafe.Pointer(&b[0]))
         ^

(The log of errors is huge, you can see a complete build log here: https://buildd.debian.org/status/fetch.php?pkg=mtail&arch=powerpc&ver=0.0%2Bgit20161027.a7b3e3c-1&stamp=1479766693)

---

For mips64el, I pressume it is just a disparity of GOARCH between gccgo and gc, and possibly could be fixed by renaminng. But I don't see any support in the code for mipsel/mipso32, alpha, or powerpc (32bits)

[NightTsarina]

By making mipsn64 an alias of mips64, I get this to compile (on mips64el). I also had to add Dup2 based on Dup3 (like in arm64) to get tests passing.

[bradfitz]

Want to send a change? https://golang.org/doc/contribute.html

/cc @ianlancetaylor

[NightTsarina]

@bradfitz I will try to prepare a proper patch for mips64, as it seems to work OK.

I was just trying to add support for mips, but I am finding some roadblocks, so that might take a while. Hopefully somebody who knows this will be faster than me :)

[anthonyfok]

@thetincho: Thank you for bringing up this issue and for pioneering the solution for mips64le, which can be found in https://anonscm.debian.org/cgit/pkg-go/packages/golang-golang-x-sys.git/commit/?id=f11a3adc214152ad98e27e7896b697cfcc376959

For probably more than I year, I had been scratching my head over this, namely, Hugo failing to build on MIPS and Alpha (etc.) architectures on Debian buildd (see https://buildd.debian.org/status/package.php?p=hugo&suite=sid). Your solution opened my eyes!

A few things happened since you visited the issue in November 2016:

• "unix: add mips and mipsle to endian files", golang/sys@7de4796 (April 2017)
• "unix: add missing dup2 syscall on mips64*", golang/sys@6b70689 (May 2017)

And it turns out that gccgo reports the same GOARCH of mipso32 on both mips and mipsel/mipsle, and mipsn64 on both mips64 and mips64el/mips64le, i.e., it seems that we cannot currently determine the endianness from GOARCH or GOHOSTARCH reported by gccgo! That perplexes me.

Anyhow, expanding on @thetincho's idea, I came up with something like this:

    cd $GOPATH/src/golang.org/x/sys/unix/
    for i in errors syscall sysnum types; do
        cp -a z${i}_linux_mips.go z${i}_linux_mips_mipso32.go
        cp -a z${i}_linux_mipsle.go z${i}_linux_mipsle_mipso32.go
        cp -a z${i}_linux_mips64.go z${i}_linux_mips64_mipsn64.go
        cp -a z${i}_linux_mips64le.go z${i}_linux_mips64le_mipsn64.go
    done

to make sure gccgo can see these files, and then run gccgo (e.g. go build) with -tags mipsle, for example, to match the files with the correct endianness. With this, go get -v -tags mipsle github.com/gohugoio/hugo (which needs golang.org/x/sys/unix) finally works with gccgo on Debian's mipsel! Yay!

For completeness, here is what I have actually used in debian/rules for the golang-golang-x-sys package: https://anonscm.debian.org/cgit/pkg-go/packages/golang-golang-x-sys.git/commit/?id=bb8f8e16490ce03ce084c8e170ea4c9e79f53ba2

I do wonder though:

• Is this the right solution?
• Was it intentional that gccgo set GOARCHs like mipso32 and mipsn64 without indicating the endianness?
• Should we modify golang.org/x/sys/unix and to add special -tags to accommodate gccgo current GOARCH values for mips* as described in the aforementioned workaround?
• Or will gccgo returns a more specific GOARCH in future releases, such that no -tags or other "hacks" are needed?

My apologies if these questions sound silly, or have been answered elsewhere before.

Many thanks!

/cc @ianlancetaylor

[bradfitz]

It seems like a bug that different GOARCH values are being used between gc and gccgo.

[NightTsarina]

@anthonyfok Thanks for picking up this issue, I did not have any spare cycles to continue the work so far..

@bradfitz That is an issue that I have experienced a few times already with the MIPS family, having to patch sources to make gccgo work

[ianlancetaylor]

I believe that the GOARCH values for MIPS have been harmonized on gccgo tip.

[paride]

This is also relevant for the sparc64 and powerpcspe architectures.

[gopherbot]

Change https://golang.org/cl/262517 mentions this issue: x/sys/unix: add linux/ppc support, for use with gccgo