Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
syscall: how to deal with ABI changes? (freebsd in this case) #16735
An interesting problem: between 8.x and 9.x in 3/2014 (see freebsd/freebsd@b38edcd#diff-6769d113f5fa92d186538ae4c8659029) some structures were changed in the kernel ABI (and thus breaking it). Current Go repo has a copy of the 8.0
In the current FreeBSD port system, we have an patch that re-sync with the current ABI (although it is currently incomplete as it does not deal with
The problem is that I'm not sure how (and have some difficulty to test right now) a go compiled binary with the modifications would work on a pre-ABI change system (although it is rather old and unsupported right now, I'd hate to break that) and how, in the go side of things, deal with that (versioned
@keltia, the patch you link to is modifying the "syscall" package, which is frozen. We even document that at the top of the page (https://golang.org/pkg/syscall/), telling users to use https://godoc.org/golang.org/x/sys/unix etc instead.
The Go runtime itself doesn't always use the "syscall" package.
For instance, for the interface data, we actually vendor a copy of https://godoc.org/golang.org/x/net/route instead (into the standard library, privately) which has been updated for various FreeBSD versions.
What was the original problem which motivated the syscall patch? It looks like http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2015-August/315441.html but that was fixed in Go 1.7 by the x/net/route vendoring.