cmd/go: add test for build -a -tags netgo -installsuffix netgo in test.bash

[ianlancetaylor]

In Go 1.4 we changed "go build -a" so that it no longer builds the standard library (issue #8290). Prior to Go 1.4, programmers who wanted a fully static binary that uses the network routinely built their programs with "go build -a -tags netgo". That no longer works. There is no longer a simple way do achieve this desirable goal. We should fix this for 1.4.1.

[minux]

I propose that we allow go build -a std to rebuild everything in std,
just go install -a std will skip any standard packages.

One interesting observation is that, with 1.4, go install -a std does
re-install something, so the fix for #8290 is actually not correct:

$ go14 version
go version go1.4 linux/amd64
$ go14 install -a -v std
cmd/internal/rsc.io/arm/armasm
cmd/internal/rsc.io/x86/x86asm
cmd/internal/objfile
cmd/addr2line
cmd/nm
cmd/objdump
cmd/pprof

[davecheney]

On 18 Dec 2014, at 08:33, Minux Ma notifications@github.com wrote:

I propose that we allow go build -a std to rebuild everything in std,
just go install -a std will skip any standard packages.

I am against more special cases, especially of this continues to encourage people to favour go build over go install.

One interesting observation is that, with 1.4, go install -a std does
re-install something, so the fix is actually not correct:

$ go14 version
go version go1.4 linux/amd64
$ go14 install -a -v std
cmd/internal/rsc.io/arm/armasm
cmd/internal/rsc.io/x86/x86asm
cmd/internal/objfile
cmd/addr2line
cmd/nm
cmd/objdump
cmd/pprof

Maybe we should just roll back the change to -a. It wasn't working before, but then as now, the REAL fix is to build go from source.

—
Reply to this email directly or view it on GitHub.

[minux]

I'd argue that it's not a new special case. The original fix is a special case, and
my proposal just tries to limit its scope:
To fix the original #8290, we don't need to limit go build -a std.

Yes, this might encourage people to use go build, but sometimes people just
want to build a one-shot statically linked binary, requiring them to build Go
from scratch is too much. (I always use tip, so that problem doesn't affect me
at all, but we've seen more than one issue reports for this problem since 1.4
is released, and this suggests we do need to something here.)

Also, I'm among the one that oppose that fix. I think a better solution for #8290
is to support another meta package that means all-std (alternatively, we can
support negative package selectors at cmd/go command line, but that's probably
too much.)

[tianon]

Given a source release, is there a way to compile in netgo from the start? We can't find a simple one, which is why Docker has resorted to these other tricks to recompile std with netgo.

It was discovered that go clean -i net && go install -tags netgo std works to get us netgo in Go 1.4, but it feels like we're playing chicken and egg here. 😄

[kostix]

Is there a way to make all.bash somehow build two copies of the relevant files, and go build|install -tags netgo then pick the "static" one? So that no rebuilding ever happens -- the user has two copies of the necessary stuff right from the start.

Please note that I'm not familiar with Go internals, just conveying what would seem to be logical to a layman. I mean, until the 1.4 release I had no idea that building a Linux binary with "static DNS lookups" (via -tags netgo) actually implied rebuilding a part of Go itself. Of coure, what I'm talking about looks like a special case but oh well... ;-)

[adg]

Does go install -a -tags netgo std yourpkg work?

[minux]

Does go install -a -tags netgo std yourpkg work?

No. it will reinstall the following packages along with all non-standard
package
dependencies of yourpkg, but not the net package.

cmd/internal/rsc.io/arm/armasm
cmd/internal/rsc.io/x86/x86asm
cmd/internal/objfile
cmd/addr2line
cmd/nm
cmd/objdump
cmd/pprof

[ianlancetaylor]

No, adding std causes the standard programs to be reinstalled but does not cause the standard library to be rebuilt.

[ianlancetaylor]

To be clear, my "no" was in reply to adg, not minux.

[ianlancetaylor]

We used to have a simple rule: the build flag -a meant to rebuild all packages even if they were up to date. We made that flag more complicated by changing it to ignore standard packages for a release build.

I propose that we restore -a to what it used to be, and add a new flag to ignore standard packages. Advantages: 1) fixes the original issue by giving people a flag to do what they want; 2) fixes this issue; 3) simplifies the meaning of -a. Cons: New flag.

[davecheney]

I like that plan.
On 7 Jan 2015 12:29, "Ian Lance Taylor" notifications@github.com wrote:

We used to have a simple rule: the build flag -a meant to rebuild all
packages even if they were up to date. We made that flag more complicated
by changing it to ignore standard packages for a release build.

I propose that we restore -a to what it used to be, and add a new flag to
ignore standard packages. Advantages: 1) fixes the original issue by giving
people a flag to do what they want; 2) fixes this issue; 3) simplifies the
meaning of -a. Cons: New flag.

—
Reply to this email directly or view it on GitHub
#9369 (comment).