Comment 1:

I've discovered this while doing race-related changes here:
https://golang.org/cl/55100044/
It makes cmd/go broken. The strange thing is that currently -race uses external linking
via cgo, and everything works...

Comment 2:

It works fine as long as you change the string so that it is not exactly "runtime/cgo".
Perhaps you could use a different string.

Comment 3:

The problem is this call in ld/lib.c:
        // Provided by the code that imports the package.
        // Since we are simulating the import, we have to provide this string.
        addstrdata("go.string.\"runtime/cgo\"", "runtime/cgo");
That defines a symbol go.string."runtime/cgo".  When the compiler sees the string
constant, it defines the same symbol to hold the string.  The compiler builds the symbol
as a string header followed immediately by the string data, and it builds a relocation
that knows that layout: a relocation to the symbol plus the size of the string header
(datastring in gobj.c).  The linker uses a different layout in addstrdata--it puts the
string header in one section and the string data in a different section.  But the symbol
name go.string."runtime/cgo" is the same in both cases, and it has to be the same or we
get other linker confusion.
So it fails when using external linking because we get a reference to an offset from the
string symbol expecting to find the string data there, but it isn't there.
I haven't quite worked out why works when using internal linking.

Comment 4:

Status changed to Started.

Comment 5:

Actually, it's obvious why it works when using internal linking: the linker only adds
the string constant when using external linking.

Comment 6:

https://golang.org/cl/58410043

Comment 7:

>Perhaps you could use a different string.
I can't. It happens in cmd/go, and it needs special handling of "runtime/cgo".

Comment 8:

This issue was closed by revision 1683dab.

Status changed to Fixed.