Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nim-nim opened this issue Mar 11, 2018 · 16 comments

Comments

@nim-nim
Copy link

nim-nim commented Mar 11, 2018

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
Copy link

@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
Copy link
Contributor

amoghe commented Oct 16, 2018

@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
Copy link

@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
Copy link
Contributor

amoghe commented Oct 16, 2018

@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
Copy link
Contributor

amoghe commented Oct 16, 2018

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
Copy link

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

@amoghe
Copy link
Contributor

amoghe commented Oct 16, 2018

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
Copy link
Contributor

amoghe commented Oct 16, 2018

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
Copy link

try this:

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

@fcrisciani
Copy link

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
Copy link
Contributor

amoghe commented Oct 16, 2018

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
Copy link

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
Copy link
Contributor

amoghe commented Oct 18, 2018

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?

@thaJeztah
Copy link
Member

I had a PR that bumped the version; #2118, but looks like it needs an update 😅

@amoghe
Copy link
Contributor

amoghe commented Oct 18, 2018

@thaJeztah thats from March . Any chance you could resuscitate it? :-)

@thaJeztah
Copy link
Member

netlink was updated in PR #2366 (revendor in moby/moby is done in moby/moby#39054)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants