syscall: define SO_REUSEPORT

[chantra]

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

1.11beta2

Does this issue reproduce with the latest release?

yes

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/chantra/local/go"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build452115149=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

Using https://gist.github.com/chantra/7783d1fe5e6e859c066aa7dcdcac5e87

On my environment:

$ go1.11beta2 run /tmp/a.go
# command-line-arguments
/tmp/a.go:12:79: undefined: syscall.SO_REUSEPORT

It works on the nacl platform: https://play.golang.org/p/BxiHNMO-4Z9

What did you expect to see?

I would expect syscall.SO_REUSEPORT to be defined. Even more so that with the apparition of the net.Listenconfig interface in go1.11, it will now be possible to set SO_REUSEPORT on sockets.
The work around in chantra/miekg-dns@e80149d is to hardcode the value for Linux amd64 platform (e.g 0xF)

$ grep SO_REUSEPORT /usr/include/ -r
/usr/include/asm-generic/socket.h:#define SO_REUSEPORT  15

What did you see instead?

$ go1.11beta2 run /tmp/a.go
# command-line-arguments
/tmp/a.go:12:79: undefined: syscall.SO_REUSEPORT

[bcmills]

The syscall package is frozen.

Is there a reason you can't use the SO_REUSEPORT from golang.org/x/sys/unix?

[chantra]

@bcmills sure I can use golang.org/x/sys/unix but given that SO_REUSEADDR & co were under syscall, I would have expected SO_REUSEPORT to be (eventually) under the same namespace.

[bcmills]

The syscall package is frozen. We generally only add to it if the additions are needed elsewhere in the runtime or standard library.

[chantra]

The syscall package is frozen. We generally only add to it if the additions are needed elsewhere in the runtime or standard library.

oh.... as in frozen for ever.... I thought you meant for 1.11 release originally.