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.

Sign up for GitHub

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

Jump to bottom

cmd/go: no easy way to install multiple binaries to desired location when cross-compiling #13063

Closed
rogpeppe opened this issue Oct 27, 2015 · 7 comments
Closed

cmd/go: no easy way to install multiple binaries to desired location when cross-compiling #13063

rogpeppe opened this issue Oct 27, 2015 · 7 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Unplanned

Comments

@rogpeppe
Copy link
Contributor

It's quite common to want to install a bunch of commands in
a single repository with "go install ./...". When packaging things
and not cross-compiling, we can use GOBIN to cause the binaries
to be written to a given directory. This doesn't work when cross-compiling
(see issue #9769), but there's no straightforward alternative.

Something like this can work, but feels clumsy:

cmds=$(go list -f '{{if (eq .Name "main")}}{{.ImportPath}}{{end}}' ./...)
cd $destdir
for i in $cmds; do
    go build $i
done

Perhaps if GOPATH has more than one element, binaries should
be installed to the first element of GOPATH, similarly to packages.

Then:

 GOPATH=$destdir:$GOPATH go install ./...

would do the trick, installing to $destdir/bin/$GOOS_$GOARCH
@bradfitz bradfitz changed the title no easy way to install multiple binaries to desired location when cross-compiling cmd/go: no easy way to install multiple binaries to desired location when cross-compiling Oct 27, 2015
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Nov 5, 2015
@james-lawrence
Copy link
Contributor

Not sure I agree that there isn't a straight forward alternative. The problem is its inconsistent.
If it consistently defaulted to $GOPATH/bin and overwrote whatever was there regardless of architecture, then we could just use GOBIN to cross compile safely. I mean the whole point of GOBIN is to specify that directory correct? I could be wrong on that...

consistency is why I suggested just using a flag to force the directory mode. #11001. That approach was to keep current behaviour, but if we don't care about maintaining that then lets just drop the creation of additional directories and emit warnings (or refuse to compile) when GOBIN isn't set and you are compiling to a non-native binary.

I don't see requiring GOBIN to be set when cross compiling would be a huge issue, we specify the majority
of those environment variable anyways when cross compiling.
i.e)

GOBIN=$PWD/darwin-amd64 GOOS=darwin GOARCH=amd64 go install ./...
GOBIN=$PWD/linux-amd64 GOOS=linux GOARCH=amd64 go install ./...

would write to different directories and be safe where as:

GOOS=darwin GOARCH=amd64 go install ./...
GOOS=linux GOARCH=amd64 go install ./...

would overwrite each other and emit a warning (or error) for one of the attempts depending if you where on mac or linux.

@simonvanderveldt
Copy link

+1

I'll explain my use case: I run go like all/most of my tooling in containers, but since I sometimes work on a Mac I need to cross-compile to make the binaries work.

Before the changes as discussed in #9769 it worked nicely for all go commands including go install. I set $GOBIN to $GOPATH/bin so the files ended up in the correct location on my Mac. After the change they end up in $GOPATH/bin/darwin_amd64.
If I set GOBIN as well as GOOS and GOARCH I get the following error go install: cannot install cross-compiled binaries when GOBIN is set

@amery
Copy link

amery commented May 23, 2017

The problem still exists in 1.8.x. the automagic ${GOPATH}/bin/${GOOS}_${GOARCH} works for darwin vs linux.... but for ARMv5 vs ARMv7 it becomes destructive :( this also affects ${GOPATH}/pkg but at least there is a -pkg option to disambiguate them there. It would be great if -o would support directories when using ./... notation

@andig

This comment has been minimized.

Sign in to view
@bcmills
Copy link
Contributor

bcmills commented Jan 23, 2019

It would be great if -o would support directories when using ./... notation

That's #14295.

@bcmills
Copy link
Contributor

bcmills commented Jan 23, 2019

Anyone have a use-case that would not be handled by #14295?

@bcmills bcmills added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jan 23, 2019
@gopherbot
Copy link
Contributor

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@golang golang locked and limited conversation to collaborators Feb 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
8 participants
@rogpeppe @amery @andig @simonvanderveldt @james-lawrence @ianlancetaylor @bcmills @gopherbot