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.

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

/cc @ianlancetaylor

@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 :)

@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

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

@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

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

This is also relevant for the sparc64 and powerpcspe architectures.

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

Change https://golang.org/cl/270317 mentions this issue: unix: define isBigEndian for all GOARCHes supported by gccgo

Change https://golang.org/cl/312349 mentions this issue: unix/linux: add ppc system call definitions, for use with gccgo