https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #37 from boger at us dot ibm.com ---
Created attachment 35260
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35260action=edit
libgo/go/go/build/doc.go documentation update
Adding comments about the use of the netgo tag and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #35 from ian at gcc dot gnu.org ian at gcc dot gnu.org ---
Author: ian
Date: Tue Apr 7 18:09:28 2015
New Revision: 221906
URL: https://gcc.gnu.org/viewcvs?rev=221906root=gccview=rev
Log:
PR go/63731
libgo: Build and install
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #36 from Ian Lance Taylor ian at airs dot com ---
Lynn added a new facility. Some notes on docs:
As far as documentation, I tried to find some documentation on build tags in
general and netgo specifically because it seems like this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #34 from boger at us dot ibm.com ---
Created a codereview: https://codereview.appspot.com/217620043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #32 from boger at us dot ibm.com ---
I have a prototype working for #2. I am assuming #1 would not be accepted.
This fix consists of building a library called libnetgo.a which consists of the
net files that would be built if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #33 from boger at us dot ibm.com ---
Created attachment 35195
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35195action=edit
Fallback netgo solution for gccgo
This patch updates the libgo Makefile to build and install the
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #30 from Ian Lance Taylor ian at airs dot com ---
The problem mentioned in comment #20 has nothing to do with gccgo. To get
around that problem, use the -installsuffix option. See
http://golang.org/issue/9344 . Note that the docker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #29 from boger at us dot ibm.com ---
Yohei noted in comment 20 that this is also broken with gc in 1.4 when using
static linking. That was a while ago -- is that no longer a problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #28 from Ian Lance Taylor ian at airs dot com ---
Currently there is no reasonable way to use the Go DNS resolver when using
gccgo. Any program that uses the net package will call glibc for DNS
resolution, meaning that you are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #27 from Tatsushi Inagaki e29253 at jp dot ibm.com ---
(In reply to Ian Lance Taylor from comment #26)
Tatsushi: are you asking about gccgo, or about gc?
I'm asking about gccgo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #26 from Ian Lance Taylor ian at airs dot com ---
Tatsushi: are you asking about gccgo, or about gc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #25 from Tatsushi Inagaki e29253 at jp dot ibm.com ---
What is the most recommended way when we want to use the net package in a
statically linked binary? My impression is that a statically linked binary also
should call dlopen() (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #20 from Yohei Ueda yohei at jp dot ibm.com ---
I noticed a Docker issue saying GC 1.4 does not rebuild the standard library
with -a.
https://github.com/docker/docker/issues/9449
I think the problem is now not limited to GCCGO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #21 from boger at us dot ibm.com ---
I'm confused by the description of -a in the go1.4 documentation.
I asked about this before and the answer was that each invocation of 'go build'
would create a copy of the built package which was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #22 from Ian Lance Taylor ian at airs dot com ---
I'm not sure why you say that it must not be the way it works. It is the way
it works.
The recent change to Go 1.4 is that the -a option does not apply to the
standard library. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #23 from boger at us dot ibm.com ---
If I look at this documentation: http://tip.golang.org/doc/go1.4#gocmd
It says this:
The behavior of the go build subcommand's -a flag has been changed for
non-development installations. For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #24 from Ian Lance Taylor ian at airs dot com ---
They would not have been overwritten, unless you used go install -a. That
line in the doc may be misleading.
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #17 from boger at us dot ibm.com ---
Can you clarify how using -a -tags netgo actually works. I know it requires
that the source be available, but it must mean that it rebuilds the package for
the current link only, throws it away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #18 from Ian Lance Taylor ian at airs dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #13 from boger at us dot ibm.com ---
Then my question is: 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? In the situation you are
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #15 from boger at us dot ibm.com ---
I think what Ian is saying is that mechanism to rebuild packages in this way
doesn't work with gccgo (and probably never should?)
Now I'm finally understanding this. Originally with gc the net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
Ian Lance Taylor ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #11 from boger at us dot ibm.com ---
What I was asking is: what does it mean to call the pure-Go goLookupIP?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #12 from Yohei Ueda yohei at jp dot ibm.com ---
pure-Go goLookupIP means that goLookupIP is written in Go as usual.
https://code.google.com/p/go/source/browse/src/net/dnsclient_unix.go#364
cgoLookupIP uses getaddrinfo via CGO unless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #9 from boger at us dot ibm.com ---
My question was: what is supposed to happen on fallback? Sounds like some
code gets rebuilt and used instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #10 from Yohei Ueda yohei at jp dot ibm.com ---
https://code.google.com/p/go/source/browse/src/net/lookup_unix.go#63
func lookupIP(host string) (addrs []IP, err error) {
addrs, err, ok := cgoLookupIP(host)
if !ok {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #4 from Yohei Ueda yohei at jp dot ibm.com ---
Thank you for the correction.
I need to use the following instructions to enable netgo with GC.
$ go version
go version devel +ae495517bd72 Fri Nov 14 11:43:01 2014 +1100 linux/amd64
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #5 from Ian Lance Taylor ian at airs dot com ---
You are correct. The go command does not rebuild the standard library for
gccgo. There is at present no reasonable way to use the netgo tag with gccgo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #6 from boger at us dot ibm.com ---
I understand why some functions like getaddrinfo don't work with static linking
unless the LD_LIBRARY_PATH is set to find libc.so, but then what should happen
if it isn't?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #7 from Ian Lance Taylor ian at airs dot com ---
That's really a question for the glibc maintainers. It's entirely a glibc
issue.
My understanding is that it's not actually libc.so that needs to be found.
Glibc implements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #8 from Yohei Ueda yohei at jp dot ibm.com ---
If we can distinguish between the not found errors due to invalid host names
and no nss, we can fall back to netgo only when nss is not available.
I noticed that errno is set to 0 for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #3 from Ian Lance Taylor ian at airs dot com ---
The gc linker does not use the external linker merely because you link against
the net package. You need to also pass -linkmode external in ldflags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #1 from Yohei Ueda yohei at jp dot ibm.com ---
Created attachment 33966
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33966action=edit
Fix the DNS lookup problem for statically linked binaries
I created a patch file that fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #2 from Yohei Ueda yohei at jp dot ibm.com ---
I tested this issue with the latest GC trunk again, and noticed that GC always
compiles programs that contains DNS lookups with dynamic linking even if
-static is specified.
$ go version
38 matches
Mail list logo
