ipvs.go:94:32: cannot use &tv (type *syscall.Timeval) as type *unix.Timeval in argument to sock.SetSendTimeout

[nim-nim]

With Go 1.9.4 x86_64 Linux

Testing: "/builddir/build/BUILD/libnetwork-2112cace8efd4c7b71daccbf54897871e205f293/_build/src/github.com/docker/libnetwork/ipvs"
+ GOPATH=/builddir/build/BUILD/libnetwork-2112cace8efd4c7b71daccbf54897871e205f293/_build:/usr/share/gocode
+ go test -buildmode pie -compiler gc -ldflags '-extldflags '\''-Wl,-z,relro  '\'''
# github.com/docker/libnetwork/ipvs
./ipvs.go:94:32: cannot use &tv (type *syscall.Timeval) as type *unix.Timeval in argument to sock.SetSendTimeout
./ipvs.go:98:35: cannot use &tv (type *syscall.Timeval) as type *unix.Timeval in argument to sock.SetReceiveTimeout
FAIL    github.com/docker/libnetwork/ipvs [build failed]

[fcrisciani]

@nim-nim the issue is not with go 1.9.4 but with the version of the netlink library that you are using to compile. For libnetwork you need to use the one that is vendored where the propotype of method is:

func (s *NetlinkSocket) SetSendTimeout(timeout *syscall.Timeval) error {

This is the commit that changed the prototype: vishvananda/netlink@0e3b74d

[amoghe]

@fcrisciani is there a reason we can't simply cast the syscall.Timeval to unix.Timeval and not have to vendor the vishvananda/netlink library?

[fcrisciani]

@amoghe they are 2 different types, they are not castable to each other, you will need to convert one into the other, but anyway that is not the only dependency that we have with netlink.

[amoghe]

@fcrisciani understood. But with libnetwork using its own vendor , I seem to be running into issues with getting dep to correctly recognize this dependency. It ends up pulling in vishvananda/netlink at v1.0.0 (which is newer than the one vendored here).

I understand this isn't strictly a libnetwork issue - but I'm not sure how to work around this. Any thoughts?

[amoghe]

The syscall.Timeval (from https://godoc.org/syscall#Timeval) is defined like this:

type Timeval struct {
    Sec  int64
    Usec int64
}

And the unix.Timeval (from https://godoc.org/golang.org/x/sys/unix#Timeval) is like this:

type Timeval struct {
    Sec  int64
    Usec int64
}

So maybe performing the cast may allow us to move to a newer version of the library (maybe the 1.0.0 ?)

[fcrisciani]

@amoghe in dep you can force with a constraint to get a specific commit id

[amoghe]

True, but since I'm not explicitly imported that lib, this is a little fragile. See this message from dep:

"github.com/vishvananda/netlink" is not imported by your project, and has been temporarily added to Gopkg.lock and vendor/.
If you run "dep ensure" again before actually importing it, it will disappear from Gopkg.lock and vendor/.

[amoghe]

I'm wondering if using the updated type will be sufficient for us to move to the 1.0.0 tag of the netlink library. Do you have any ideas as to what else would need to be handled to facilitate the version bump up?

[fcrisciani]

try this:

[[contraint]]
name = "github.com/vishvananda/netlink"
revision = "b2de5d10e38ecce8607e6b438b6d174f389a004e"

[fcrisciani]

not sure, I did not spend time trying to change the revision, it can be easy as only fixing that type but the problem can still appear when libnetwork is vendored inside moby/mody for integration

[amoghe]

If you're open to the change - I can try to bump the lib to 1.0.0 .

By moving to a specific version (1.0.0) instead of a git hash - we should, in theory, make future upgrades easier since API changes across versions should be easier to track down. So even though this problem may occur in the future, it should be a little easier to solve, no?

[fcrisciani]

you can give it a shot, but I would try to bump in moby/moby directly and identify all the places where there is the issue

[amoghe]

Does moby/moby consume this lib? If so, then here's what I'll do:

1. update this lib
2. try building moby with this lib

Or are you suggesting something else?