Skip to content

go/build: does not know about buildmode pkg directories #16378

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

Closed
josharian opened this issue Jul 14, 2016 · 4 comments
Closed

go/build: does not know about buildmode pkg directories #16378

josharian opened this issue Jul 14, 2016 · 4 comments
Milestone

Comments

@josharian
Copy link
Contributor

Create and build/install imp.go:

package main

import (
    "fmt"
    "go/build"
    "log"
)

func main() {
    pkg, err := build.Import("fmt", "", build.FindOnly|build.AllowBinary)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(pkg.PkgObj)
}

Then try to use it with darwin/arm:

$ GOOS=darwin GOARCH=386 go install std
$ GOOS=darwin GOARCH=arm go install std
$ cd $GOROOT/pkg
$ pwd
/Users/josh/go/tip/pkg
$ ls -d darwin_arm* darwin_386*
darwin_386      darwin_arm_shared
$ GOOS=darwin GOARCH=386 ./imp
/Users/josh/go/tip/pkg/darwin_386/fmt.a
$ GOOS=darwin GOARCH=arm ./imp
/Users/josh/go/tip/pkg/darwin_arm/fmt.a

Observe that the installed arm packages are in darwin_arm_shared, but according to go/build, the PkgObjs are to be found in darwin_arm.

This comes up in practice when attempting to do a cross-platform go vet invocation, because vet cannot find the fmt (and other) packages, which results in a flood of incorrect errors.

I'd love help fixing this. I'm not sure what/where the correct fix is, or even who to ask for help. This will shortly block my progress on #11041, so an R=go1.8 CL would be deeply appreciated.

@josharian josharian added this to the Go1.8 milestone Jul 14, 2016
@ianlancetaylor
Copy link
Member

I expect that cmd/go/build.go needs to update buildContext.InstallSuffix.

@ianlancetaylor
Copy link
Member

Hmmm, sorry, it already does that. But I guess the problem is that cmd/vet doesn't know about the installsuffix.

I see: the buildModeInit functions sets an install suffix of "shared" as the default for several targets: "android/arm", "android/arm64", "android/amd64", "android/386", "darwin/arm", "darwin/arm64". For "darwin/arm" and "darwin/arm64" it's odd that not passing a -buildmode option is not the same as passing an explicit -buildmode=archive or -buildmode=exe option. I'm not sure what the right fix is. If we are always going to pass -shared to the compiler, then perhaps we should not be setting the install suffix in that case.

@josharian
Copy link
Contributor Author

Thanks, Ian, that was exactly the information I needed to get unstuck. I'll send a CL shortly for preliminary feedback.

josharian added a commit to josharian/go that referenced this issue Jul 14, 2016

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…atforms

DO NOT SUBMIT

[code freeze]

Fixes golang#16378.

Change-Id: I99a064f1afec78fb63cb3719061d20be0f21d45d
@gopherbot
Copy link
Contributor

CL https://golang.org/cl/24930 mentions this issue.

josharian added a commit to josharian/go that referenced this issue Jul 21, 2016
DO NOT SUBMIT

[code freeze]

Fixes golang#16378.

Change-Id: I99a064f1afec78fb63cb3719061d20be0f21d45d
josharian added a commit to josharian/go that referenced this issue Jul 21, 2016
DO NOT SUBMIT

[code freeze]

Fixes golang#16378.

Change-Id: I99a064f1afec78fb63cb3719061d20be0f21d45d
@golang golang locked and limited conversation to collaborators Aug 26, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants