https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #19 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #18) > The -a option to "go build" means to rebuild all packages rather than using > the installed versions (see http://golang.org/cmd/go for documentation). > The "-tags netgo" option means to build with the build tag netgo (see the > build constraints section in http://golang.org/pkg/go/build/). So, yes, it > rebuilds the packages for the current link only. This is more reasonable > with the gc compiler than with gccgo, since the gc compiler is so fast. > Most of the examples in the documentation show that the built packages are put into the same directories as the source. I assume that for an official release with a binary distribution, that is not the way it works. That's how it would have to work with gccgo. In that case everyone must share the same copy of the source but then if build options are used that would cause packages to be rebuilt, they must go somewhere that is only used for the curent build. And I don't understand what 'go install' would mean in that case. The 'go install' command documentation has very little information on where built packages are stored or if there are cases when 'go install' can't be used. > I'm OK in principle with coming up with some other approach to direct the Go > library to use the Go DNS lookup rather than calling getaddrinfo. I don't > think that can be the default. I don't think we want a program to > unpredictably sometimes use one and sometimes use the other. I don't think > an environment variable would work well, since Yohei presumably wants the > statically linked binary to work this way by default. Unfortunately all I > can think of would be adding another function to the net package directing > lookups to use pure DNS; this is unfortunate because the net package already > has the most complex and confusing API of all the standard Go packages. I think providing another function that called the pure GO resolver would be best. Then the GO programmer can decide how to handle it if the first call failed.
