== Go, IPv6, and single binding machines

The current libraries for the [[Go language http://golang.org/]]
and their built in tests strongly believe that you can talk to IPv4
addresses through IPv6 sockets, which is [[not necessarily the case
../programming/ModernSocketsListening]]. This is a [[known issue
http://code.google.com/p/go/issues/detail?id=679]] ([[see also
http://code.google.com/p/go/issues/detail?id=538]]), and is more
than somewhat inconvenient on a machine with [[dual binding turned
off ../linux/Ipv6DualBinding]], such as my workstation, as Go will
not install from source unless all its tests pass.

(Since Debian has apparently [[changed their minds about dual binding
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560238]], this may
not affect very many people. I maintain that it should, although it's
now a quixotic battle that I am probably not going to win any time
soon.)

If this affects you, the simple fix is probably to just apply the
patch from [[Joerg Sonnenberger
http://code.google.com/u/joerg.sonnenberger/]] that's (currently)
at the end of [[Go issue 679
http://code.google.com/p/go/issues/detail?id=679]]. I opted for a
slightly different fix, because I wanted to force Go to use IPv4
sockets where possible. Thus, I forced _preferIPv4_ in
src/pkg/net/ipsock.go to _true_ and applied only his patch to
src/pkg/net/sock.go to always turn off ((IPV6_V6ONLY)) on IPv6
sockets.

(A more thorough fix for _preferIPv4_ would be to test if the kernel
let you bind IPv4 addresses to an IPv6 socket. But I didn't feel like
going to that much effort for what is ultimately a quick hack that the
Go maintainers are unlikely to support.)

While this is an incomplete hack with some limits, I think it is
generally going to do what I want from Go [[even with servers
../programming/ModernSocketsListening]], provided that I am careful
(basically I can't mix an explicit IPv4 server with a Go-based IPv6
one). A better fix would be to change the code to explicitly force
((IPV6_V6ONLY)) only when we are using IPv6 sockets with IPv4 addresses,
and I may try that fix at some point when I feel more ambitious about
hacking up the innards of Go packages.

(One of the attraction of Go is that it looks familiar enough to me that
I can fumble my way through this sort of chainsaw modifications and
usually get them to work.)

As a side note: since OpenBSD doesn't allow dual binding under any
circumstances, this is going to be a real issue if anyone ever attempts
to port Go to OpenBSD. I suspect that the solution will be to turn off a
bunch of tests.