The various asm files in x/sys are not used by gccgo. For example, asm_linux_loong64.s has a go:build line that says that the file is only built with the "gc" tag. That means it is only built when using the gc compiler, not when using gccgo.

You'll need to add a cpu/cpu_sparc64.go file to define cacheLineSize appropriately, and you'll need to figure out why the sparc64 build tag was not used to pick up unix/endian_big.go.

Thanks for the info!! Glad to know I don't need to learn sparc64 asm :D.

I added the cpu_sparc64.go file, and it builds successfully! The bigendian error disappeared after that. Black magic o.o

I am a bit confused for what to set cacheLineSize to. Different sparc64 CPUs have different values, looking at cpu_arm64.go it seems like I should use the highest of the bunch?

Sadly, it looks like it fails a good deal of tests:

root@sparcy /var/tmp/tmp/sys-sparc64 # go test ./...
ok      golang.org/x/sys/cpu    0.174s
ok      golang.org/x/sys/execabs        0.170s
ok      golang.org/x/sys/internal/unsafeheader  0.179s
--- FAIL: TestPktInfo (0.01s)
    --- FAIL: TestPktInfo/udp4 (0.00s)
        ???:1: Got packet from 0.0.0.0, want 127.0.0.2
    --- FAIL: TestPktInfo/udp6 (0.00s)
        ???:1: Got packet from ::, want 2001:db8::1
--- FAIL: TestDevices (0.00s)
    --- FAIL: TestDevices//dev/null_1:3 (0.00s)
        ???:1: for /dev/null Major(0x0) == 0, want 1
        ???:1: for /dev/null Minor(0x0) == 0, want 3
        ???:1: for /dev/null Mkdev(1, 3) == 0x103, want 0x0
    --- FAIL: TestDevices//dev/zero_1:5 (0.00s)
        ???:1: for /dev/zero Major(0x0) == 0, want 1
        ???:1: for /dev/zero Minor(0x0) == 0, want 5
        ???:1: for /dev/zero Mkdev(1, 5) == 0x105, want 0x0
    --- FAIL: TestDevices//dev/random_1:8 (0.00s)
        ???:1: for /dev/random Major(0x0) == 0, want 1
        ???:1: for /dev/random Minor(0x0) == 0, want 8
        ???:1: for /dev/random Mkdev(1, 8) == 0x108, want 0x0
    --- FAIL: TestDevices//dev/full_1:7 (0.00s)
        ???:1: for /dev/full Major(0x0) == 0, want 1                       
        ???:1: for /dev/full Minor(0x0) == 0, want 7                       
        ???:1: for /dev/full Mkdev(1, 7) == 0x107, want 0x0                
    --- FAIL: TestDevices//dev/urandom_1:9 (0.00s)                         
        ???:1: for /dev/urandom Major(0x0) == 0, want 1                    
        ???:1: for /dev/urandom Minor(0x0) == 0, want 9                    
        ???:1: for /dev/urandom Mkdev(1, 9) == 0x109, want 0x0             
    --- FAIL: TestDevices//dev/tty_5:0 (0.00s)                             
        ???:1: for /dev/tty Major(0x0) == 0, want 5                        
        ???:1: for /dev/tty Mkdev(5, 0) == 0x500, want 0x0                 
--- FAIL: TestStatx (0.00s)
    ???:1: Statx: returned stat mode does not match Stat
    ???:1: Statx: returned stat ctime does not match Stat
    ???:1: Statx: returned stat mtime does not match Stat
    ???:1: Statx: returned stat mode does not match Lstat
    ???:1: Statx: returned stat ctime does not match Lstat
    ???:1: Statx: returned stat mtime does not match Lstat
--- FAIL: TestFstatat (0.00s)
    ???:1: Stat/Fstatat: got dev 30, expected 128849018880
    ???:1: Stat/Fstatat: got ino 1, expected 142541374685184
    ???:1: Stat/Fstatat: got mode 33188, expected 0
    ???:1: Stat/Fstatat: got size 8192, expected 1663186338
    ???:1: Lstat/Fstatat: got dev 30, expected 128849018880
    ???:1: Lstat/Fstatat: got ino 1, expected 178116588797952
    ???:1: Lstat/Fstatat: got mode 41471, expected 0
    ???:1: Lstat/Fstatat: got size 8192, expected 1663186338
--- FAIL: TestFchmodat (0.00s)
    ???:1: Fchmodat: failed to change symlink mode: expected -rwxrwxrwx, got ----------
--- FAIL: TestUtimesNanoAt (0.00s)
    ???:1: UtimesNanoAt: wrong mtime: got {0 0}, expected {3333 0}
FAIL
FAIL    golang.org/x/sys/unix   0.988s
ok      golang.org/x/sys/unix/internal/mkmerge  0.290s
?       golang.org/x/sys/windows/mkwinsyscall   [no test files]
FAIL

You can take a look at the cpu_sparc64.go I wrote here.

Any tips on where to go from here? Am a bit lost on where these tests might be failing..

I appreciate your time :)

Yes, cacheLineSize should be the largest cache size used on the processor architecture.

The tests suggest that Stat isn't working, which suggests that the Stat_t type in the file ztypes_linux_sparc64.go is somehow incorrect. That is just a guess, though.

aaaaahrg I'm getting stuck on this.

I'm not using the docker method, as I want the information from my running system to be used, to see if there's any differences. Plus, Docker('s deps) requires go 1.18 to build. As far as I'm aware, gcc12 only supports up to go 1.16.

I took a look at Stat_t, and I have 0 idea how to fix this by hand. Looking at mkpost.go, I of course commented out the docker check, but it seems to hang endlessly. Using print messages I narrowed down the freezing to this line:

b, err := ioutil.ReadAll(os.Stdin)

I'm running it directly like this, not sure if this is how I'm supposed to do it:

GOOS="linux" GOARCH="sparc64" go run mkpost.go

I keep looking at the test results, then the tests, and I'm just.... baffled. Like TestPktInfo. The test is so so simple, and it fails miserably. Same thing with the /dev/random test....

I'll keep assuming it's something wrong in ztypes_linux_sparc64.go (or one of the other unix/*linux_sparc64.go files).

I'll keep working on it, but in the meantime, if I can get some hints with this mkpost.go (or any possible alternative ways to get the info I need) I would SUPER greatly appreciate it :D

Update: Writing a script to try every possible value combination in Stat_t. Will leave overnight, maybe, just maybe, by morning I'll have something that passes tests :D

So I finally understood what to do to generate these the right way. I don't really know go, so they were hard for me to follow, and I misunderstood.
Although when I run go tool cgo -godefs linux/types.go, I get an error about not being able to find abi/abi.h. Which, is generated with mkall.go. However when I go run mkall.go, I get an error about needing to be on amd64. An interesting chicken and the egg scenario :D

Anyways, I'm again back to getting the values by hand. The whole script thing I mentioned above didn't work too well :/.

I'm trying to adapt /usr/include/asm/stat.h, and comparing it to ztypes_linux_sparc64.go, but in the ztypes I see this Timespec field for the time values. At the moment I'm leaving that as is, as I don't understand what it is, but is there a chance this could be incorrect?