https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #31 from boger at us dot ibm.com --- Here are two suggestions to solve this issue without having to use the -a and -tags netgo options to rebuild packages at build time. Since this is a common problem, it seems best to provide a way to have the packages built and provided with the gccgo build instead of requiring users to know how to rebuild the net package with netgo. 1) Since libgo is provided for both static (libgo.a) and dynamic (libgo.so.N) linking, and the problem only happens with static linking, we could build libgo.a with netgo enabled, so that would be the expected/default behavior with static linking with gccgo. 2) As part of the gccgo and libgo build, build just the net package with netgo enabled and install it somewhere that is easily found, using the normal directory conventions for GO. Then if someone builds a program for static linking and want the GO DNS resolver, they could link in that package before they link in libgo.a.
