https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #14 from Yohei Ueda <yohei at jp dot ibm.com> --- I am not the original author, so my description may be inaccurate. > why isn't this "fallback" code always built for GO and available > to run instead of waiting until it hits this situation and then > built and run? The fallback code (goLookupIP) is always built, but is called at run time only when the code is built with the netgo tag. When the netgo tag is not set at build time, both cgoLookupIP and goLookupIP are always built. However, only cgoLookupIP is called, and goLookupIP is never called at run time. So, lookup fails when it is statically linked. When the netgo tag is set at build time, cgoLookupIP is empty and goLookupIP is built. So only goLookupIP is called at run time. lookupIP looks like it has a run time fallback mechanism, but it is not true. The current code only selects cgoLookupIP or goLookIP at build time depending on the netgo tag setting. If we could distinguish "not found" errors of getaddrinfo as described earlier, lookupIP could have a run time fallback mechanism from cgoLookIP to goLookupIP. However, it is impossible to distinguish "not found" errors as far as I know, so I guess the current code depends on the netgo tag to select cgoLookupIP or goLookupIP at build time. > In the situation you are describing it sounds like it is related to > whether or not there is a static libnss available which could be determined > at GO build time. The existence of libnss at build time does not affect the behavior at run time. The netgo tag affects which lookup function is called at runtime.
