[Bug go/63731] Fallback to netgo does not work

yohei at jp dot ibm.com gcc-bugzilla@gcc.gnu.org
Thu Nov 20 14:49:00 GMT 2014


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.



More information about the Gcc-bugs mailing list