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

x/vgo: OS specific requirements don't appear to be added to the go.mod #24367

IngCr3at1on opened this issue Mar 13, 2018 · 1 comment


Copy link

commented Mar 13, 2018

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


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


What did you do?

I added a go.mod file to an existing project and ran vgo build. The following require lines were added to the .mod file as expected:

require (
	"" v1.4.4
	"" v1.0.5
	"" v0.0.0-20180312195533-182114d58262

and vgo attempted to compile the application

What did you expect to see?

the application to be compiled into a binary

What did you see instead?

../../../../v/ undefined: unix.IoctlGetTermios
../../../../v/ undefined: unix.IoctlGetTermios
../../../../v/ undefined: unix.IoctlSetTermios
../../../../v/ undefined: unix.IoctlGetTermios
../../../../v/ undefined: unix.IoctlSetTermios
../../../../v/ undefined: unix.IoctlGetWinsize
../../../../v/ undefined: unix.IoctlGetTermios
../../../../v/ undefined: unix.IoctlSetTermios
../../../../v/ undefined: unix.IoctlSetTermios

I can get around this error obviously by running vgo get

@gopherbot gopherbot added this to the vgo milestone Mar 13, 2018


This comment has been minimized.

Copy link

commented Mar 30, 2018

This is a "garbage in" problem, not a problem in vgo itself. has which asks for a specific commit of x/sys. does not declare its dependencies at all, but it turns out to need a newer version of x/sys than the one requested by labstack/echo. Since the requirement on the newer version is unstated, vgo obviously doesn't know about it, so it keeps using the older one, leading to the missing IoctlGet* symbols.

This is a fundamental problem: if packages depend on something they don't mention in their requirements lists, then they might not get the right version of that thing. There's not much we can do about it once it happens. In the long term, once everything is being built with vgo (when it becomes "go"), everything will declare its requirements, since go.mod is updated automatically, and the problem will not happen anymore.

@rsc rsc closed this Mar 30, 2018

@golang golang locked and limited conversation to collaborators Mar 30, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
3 participants
You can’t perform that action at this time.