Go 1.17: ostime / runtime.walltime linking error

[jmailaender]

Hi there,

first of all, many thanks for this great piece of work!

I'm trying to run the latest release 1.2.0 on OSX 11.5.2 with Go 1.17.1 but tests and builds fail with the error github.com/muyo/sno.snotime: relocation target runtime.walltime1 not defined respectivly /Users/dm/go/pkg/mod/github.com/muyo/sno@v1.2.0/internal/time.go:36: undefined reference to runtime.walltime1'.

I'm not sure if this is an issue with sno or something has changed in the recent go versions, but it works by linking ostime to runtime.walltime instead of walltime1.

Cheers
David

[azhai]

Me too.
Golang 1.17.2 x86_64
WSL Ubuntu 20.04 in Win10

/opt/go-1.17/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/bin/ld: /tmp/go-link-648231143/go.o: in function `github.com/muyo/sno.snotime':
go.go:(.text+0x1fff73): undefined reference to `runtime.walltime1'
collect2: error: ld returned 1 exit status

make: *** [Makefile:25: build] Error 2

[azhai]

In Golang 1.17 change
//go:linkname ostime runtime.walltime1
to
//go:linkname ostime runtime.nanotime

[alcore]

Apologies for taking so long - and thanks for both reporting and looking into it!

This ended up being less trivial than I hoped. Linking against runtime.walltime under Go 1.17 works for all targets... except Linux/amd64, as the corresponding assembly was removed from the runtime package (vide golang/go@b15372f). I decided to roll out a temporary solution for this target via a543713 but will look into something more feasible for a proper next release, considering Linux/amd64 is my primary optimization target and the time fetching calls are where most of the time is spent.

The fixes are tagged and released as 1.2.1. CI reports them as green on both 1.14 and 1.17 on all tested platforms so hopefully this will properly slip through as a minor release without breakage.

--

@azhai, @npaton: runtime.nanotime returns a monotonic clock reading, not a wall clock reading, meaning when the clock resets (upon reboot etc.), you'd start getting colliding IDs. Plus, the actual time (ie. local time) does not get embedded either, of course. So while it'd make the lib compile - it wouldn't work correctly.