proposal: cmd/go: bundle GOROOT in cmd/go tool #36266
Comments
|
You do not need GOROOT to run a binary. A binary contains everything to run itself. You just need libc (conditionally) to exist. I am going to close this as this doesn't sounds like a bug. But please feel free to ask it in any of these forums below:
Thanks |
|
The idea was to bundle the GOROOT inside the `go` binary.
The one you use `go build` with.
…On Tue, Dec 24, 2019, 8:59 AM Agniva De Sarker ***@***.***> wrote:
Closed #36266 <#36266>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#36266?email_source=notifications&email_token=ACPQOXTCYIB7VAHBBWW2EJLQ2I5VJA5CNFSM4J63JHF2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVVD2Y2A#event-2907155560>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPQOXWGYDRXD62UPBR52ZLQ2I5VJANCNFSM4J63JHFQ>
.
|
|
The system on which you run |
|
Nono. That's not the idea.
The idea was to bundle the GOROOT into the standard go binary. So that the
user could plop the bundled binary onto a flash drive, and have beable to
`go build` without having to set the GOROOT environment variable.
For example, on windows there would only be one file needed with this idea,
`go.exe`, without needing to set GOROOT to somewhere on the flashdrives.
…On Tue, Dec 24, 2019, 9:08 AM Keith Randall ***@***.***> wrote:
The system on which you run go build is not necessarily the system where
you run the resulting binary.
The system where you run the binary might not have Go installed at all.
This happens especially in the case of cross-compilation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#36266?email_source=notifications&email_token=ACPQOXQ5E5ILE7UV5FLUVDLQ2I6YBA5CNFSM4J63JHF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHTOIAA#issuecomment-568779776>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPQOXUIDHVHHH34CC5RR4DQ2I6YBANCNFSM4J63JHFQ>
.
|
|
I don't think we are likely to implement this, but I agree that it makes sense conceptually, so reopening. |
ianlancetaylor
changed the title
|
Like I said, it's a idea that is semi useless, but it could have some kind
of use case. An edge case yes.
…On Wed, Dec 25, 2019, 6:12 PM Ian Lance Taylor ***@***.***> wrote:
Reopened #36266 <#36266>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#36266?email_source=notifications&email_token=ACPQOXQDQATNSTQ2B35IFJ3Q2QHKTA5CNFSM4J63JHF2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVVMRPKY#event-2908297131>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPQOXWWZWD7OPDOB3UVFBTQ2QHKTANCNFSM4J63JHFQ>
.
|
|
I see, I misunderstood what you were suggesting. This would be challenging. Currently the Go tools (compile, link, asm, etc.) are all separate binaries. If we just packed their data into the All those tools would then need to be able to access the stdlib, which we'd also have to unpack somewhere. Or have those tools be able to read files from a packed (.zip?) format in the binary itself? The Go distribution directory also provides a place to cache build artifacts (the Finally, there'd be no place for a bunch of ancillary stuff, like the license, docs, tests. |
|
Or. As I have done with a few side expirements
Take each program (like the link, asm stuff.) and rename the main()
function and call it?
So that when those executables are called, it calls the function instead.
Yeah the tmp dir thing would be tricky, maybe since a user would set their
gopath perferably, use that? And if GOPATH is not set, warn that the tool
may not work/behave as intended.
And if the user has GOPATH set, we could use `$GOPATH/tmp`? Or
`$GOPATH/pkg`?
…On Fri, Dec 27, 2019, 8:40 AM Keith Randall ***@***.***> wrote:
I see, I misunderstood what you were suggesting.
This would be challenging. Currently the Go tools (compile, link, asm,
etc.) are all separate binaries. If we just packed their data into the go
binary as is, then to run them we'd need to copy them out to a temporary
location, chmod+x them, and then run them. We could also make the go
binary a swiss army knife that contains all the tools in a single binary,
and it could re-exec itself to access the tools.
All those tools would then need to be able to access the stdlib, which
we'd also have to unpack somewhere. Or have those tools be able to read
files from a packed (.zip?) format in the binary itself?
The Go distribution directory also provides a place to cache build
artifacts (the pkg directory). We'd need to figure out a new place for
that (if we used a temp dir, then there'd be no build caching between
invocations).
Finally, there'd be no place for a bunch of ancillary stuff, like the
license, docs, tests.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#36266?email_source=notifications&email_token=ACPQOXTNHKEPG6QBVICKDLTQ2YVY3A5CNFSM4J63JHF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHXOE3A#issuecomment-569303660>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPQOXXCC6Q7553Y657C4DDQ2YVY3ANCNFSM4J63JHFQ>
.
|
|
If you really want this, one approach would be to make a container and run it under podman. For all the reasons outlined in the discussion above, this seems like a likely decline. Leaving open for a week for final comments. |
|
Well I recently found out about bin-data, which could make this easier if
done right.
But yeah, I originally opened it knowing it was gonna get shot down, but
primarily to plant the concept in people who are more confident in their
coding skills than I.
…On Wed, Jan 8, 2020, 10:53 AM Russ Cox ***@***.***> wrote:
If you really want this, one approach would be to make a container and run
it under podman.
Another approach would be to put the entire GOROOT file system onto the
USB stick.
For all the reasons outlined in the discussion above, this seems like a *likely
decline*.
It would be a lot of work to duplicate things that can already be done in
other ways today.
Leaving open for a week for final comments.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#36266?email_source=notifications&email_token=ACPQOXQTZGMJ6IFQWISZ3YDQ4YOI3A5CNFSM4J63JHF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEINSYVQ#issuecomment-572206166>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPQOXWFJDHEBPONGXB6KHLQ4YOI3ANCNFSM4J63JHFQ>
.
|
|
No change in consensus, so declining. |
So here is the idea/concept,
I was looking at the details that
go buildbundles the needed runtimes inside the compiled binary for the program to run (hence why a simple hello world is 2mb),I was thinking if the base stuff could be bundled into the main binary? So that the need for a
GOROOTwould not exist?This idea came to mind when I was trying to work off a flashdrive as it was one less factor I would have to worry about breaking when I updated some component of my USB.
Technically speaking, could this exist? If so, how practical would it be?
Sure the bundled Binary would be 300+mb in size, maybe less if done right (maybe removing unnecessary components? Like documentatiob for example if that's a thing.)
The text was updated successfully, but these errors were encountered: