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=35260&action=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 ---
Author: ian
Date: Tue Apr 7 18:09:28 2015
New Revision: 221906
URL: https://gcc.gnu.org/viewcvs?rev=221906&root=gcc&view=rev
Log:
PR go/63731
libgo: Build and install libnetgo.a
libnetgo.a pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #36 from Ian Lance Taylor ---
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 should be documented
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 #33 from boger at us dot ibm.com ---
Created attachment 35195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35195&action=edit
"Fallback" netgo solution for gccgo
This patch updates the libgo Makefile to build and install the li
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 netg
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 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #30 from Ian Lance Taylor ---
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 issue mentioned in
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 ---
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 limited to what glibc will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #27 from Tatsushi Inagaki ---
(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 ---
Tatsushi: are you asking about gccgo, or about gc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #25 from Tatsushi Inagaki ---
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 thus we should export LD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #24 from Ian Lance Taylor ---
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 #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 inst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #22 from Ian Lance Taylor ---
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 don't know whether tha
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 #20 from Yohei Ueda ---
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 #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 #18 from Ian Lance Taylor ---
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
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 aft
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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 pac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #14 from Yohei Ueda ---
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
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 describ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #12 from Yohei Ueda ---
"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 the netgo tag is set.
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 #10 from Yohei Ueda ---
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 {
addrs, err
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 #8 from Yohei Ueda ---
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 invalid hostnames, and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #7 from Ian Lance Taylor ---
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 /etc/nsswitch.conf by loading
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 #5 from Ian Lance Taylor ---
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 #4 from Yohei Ueda ---
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
$ go build -ldflags '-link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #3 from Ian Lance Taylor ---
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 #2 from Yohei Ueda ---
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
go version devel +ae495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #1 from Yohei Ueda ---
Created attachment 33966
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33966&action=edit
Fix the DNS lookup problem for statically linked binaries
I created a patch file that fixes this problem.
38 matches
Mail list logo
