Comment 1:

Owner changed to @ianlancetaylor.

Status changed to Accepted.

Comment 2:

why link pure-Go programs with the system linker?

Comment 3:

At least on Fedora, the 2 main reasons I see for linking with the system linker are:
 build-id support: http://fedoraproject.org/wiki/Releases/FeatureBuildId
 GNU_HASH support: http://www.sourceware.org/ml/binutils/2006-06/msg00418.html
Both of these could be added to 6l (and indeed 6l has partial build-id support), but
until then it would be nice if the external linker was an option. Plus, this allows for
future system-dependent features to be added to the system linker without needing
special support in 6l.

Comment 4:

Putting this on the Go 1.1 list to decide what to do; this is not a promise that it will
be fixed for Go 1.1.

Labels changed: added go1.1.

Comment 5:

https://golang.org/cl/8716044

Status changed to Started.

Comment 6:

This issue was closed by revision 6969012.

Status changed to Fixed.

Comment 7:

This seems to break building of go with GO_LDFLAGS="-linkmode external".
It is now refusing to build runtime/cgo.a, I get many messages during the build
"warning: unable to find runtime/cgo.a". When I try to run cgo itself, I get a segfault,
which makes some sense because I guess it is missing its own runtime code?

Comment 8:

i think we really shouldn't build non-cgo Go programs with
-linkmode external, because it's not free, as it makes
the program depending on runtime/cgo it has many consequences.
(for one, the Go command will fail to see its pseudo dependency
on runtime/cgo, for another, it will lose the static linking
feature enjoyed by normal non-cgo programs)
I suggest we revert rev 54957b8906eb for Go 1.1 and reconsider
this issue after Go 1.1 is released (for one, i think external
linking a non-cgo program should still produce a static binary).

Comment 9:

I don't see why we should support building Go itself with GO_LDFLAGS="-linkmode
external".  That seems designed for failure.
This bug has a real use case for using -linkmode external.  If you want to use -linkmode
external and get a statically linked binary, it's easy enough to use -extldflags -static.
The dependency on runtime/cgo is a fair point but I don't think it is a major one for
most people.

Comment 10:

ah, sorry, i don't know that external link can produce static binary
with -extldflags -static now.

Comment 11:

Building Go with linkmode external is my main motivation for this bug, to enable the
various linker-provided features available in Fedora.
Why is Go itself special in this regard?

Comment 12:

currently, building Go code with external linking mode means
to force it to use cgo and switch to use pthread to create
threads (instead of calling clone(2) directly), so every OS
thread incurs a bigger thread stack penalty (as we need to
accommodate pthread's requirement).
using cgo means every program needs runtime/cgo, but there
is circular dependency:
runtime/cgo needs cmd/cgo to build,
but when building in external linking mode, cmd/cgo needs
runtime/cgo.
To fix this, we must first build a internal linked copy of
cmd/cgo to bootstrap the whole process. This is doable,
but not at this stage.

Comment 13:

Aha, I did not realize the extent of the changes. The pthreads requirement seems
especially invasive. Thanks for the explanation.
So it seems that at this point, a better approach would be to extend the Go linker to
support the features needed directly. I'll perhaps file some feature request bugs for
tracking this separately.

Comment 14:

Can you explain why you want to do this?  Do you specifically want a
linker build ID in the Go binaries themselves?

Comment 15:

Yes, the Go binaries should have a build-id in them on Fedora. This helps because Fedora
extracts the debug symbols during build and packages them separately. The build-id
allows the system to correctly find (and download) the correct debuginfo package for any
given binary.
http://sourceware.org/binutils/docs-2.23.1/ld/Options.html#index-g_t_002d_002dbuild_002did-271
Go's linker has the build-id support, but does not currently implement the exact sha1
hashing that the system linker does.
Actually, perhaps the best way forward is to figure out how to put build-id information
into an arbitrary existing binary. This would solve the issue in a general way without
anything special from Go.