cmd/cgo: weird "packagename(.text): undefined: packagename(/somenumber)" errors linking some complex projects on real Windows with MinGW-w64/gcc 4.9.x

[andlabs]

This issue perplexes me to the point that I'm not able to reproduce it using a minimal
example.

andlabs/ui#29
A bunch of people have reported in my GUI package (github.com/andlabs/ui) is spitting
out numerous errors such as

github.com/andlabs/ui(.text): undefined: github.com/andlabs/ui(/1124)
github.com/andlabs/ui(.text): undefined: github.com/andlabs/ui(/1081)
github.com/andlabs/ui(.text): undefined: github.com/andlabs/ui(/1031)
github.com/andlabs/ui(.text): undefined: github.com/andlabs/ui(/982)

during the executable link process.

What Wessie in #go-nuts and myself have gathered is:

- this happens with any configuration of gcc 4.9.x from MinGW-w64
- this happens on real Windows, not with the Linux cross-compilers
- Windows version doesn't matter (I've confirmed this with the Windows 10 Technical
Preview)

As mentioned, I tried writing several different possible minimal examples, but none of
them have exhibited this problem.

Thanks...

[andlabs]

Comment 1:

Wessie has also mentioned that some other problems may be exhibiting this problem.
I'm not sure if the bug is on my end or in Go's, but since it happens only on specific
configurations I am thinking to try here first.

[andlabs]

Comment 2:

Oh, this appears to be a duplicate of issue #8811, though that one has different
environment parameters...

[andlabs]

Comment 3:

Oh, this appears to be a duplicate of issue #8811, though that one has different
environment parameters...
[10:33] <Wessie> that one claims it doesn't work with 4.8.3 though, which it does
[10:33] <Wessie> the ui one that is

[gopherbot]

Comment 4 by [email protected]:

This happens with go versions 1.2.2, 1.3.2 and 1.3.3, I have not tested tip at this
point in time. It happens with mingw-64 installations with gcc4.9.x and works fine on
gcc4.8.3
The issue linked above, issue #8811 does not work on gcc4.8.3 according to the reporter.
So this probably means they're different albeit similar issues

[ianlancetaylor]

Comment 5:

We're unlikely to make progress on this unless somebody can figure out how to reproduce
it.
If you have a reproducible test case, does it happen if you use -ldflags=-w?

Labels changed: added repo-main, release-go1.4maybe.

[andlabs]

Comment 6:

I modified src/cmd/ld/ldpe.c to dump the string table and decided to extract the string
list for the undefined symbols:
1867 - .rdata$.refptr.fv_RemoveWindowSubclass
1906 - .rdata$.refptr.fv_DefSubclassProc
1838 - .rdata$.refptr.storeAreaHWND
1813 - .rdata$.refptr.hInstance
1785 - .rdata$.refptr.hDefaultIcon
1757 - .rdata$.refptr.hArrowCursor
1735 - .rdata$.refptr.msgwin
1699 - .rdata$.refptr.fv_SetWindowSubclass
All except storeAreaHWND are C-side variables of varying type (a few function pointers
dynamically loaded, some Windows API handles, etc.).
storeAreaHWND is weirder: it's a Go function //exported but never called directly from
C: instead it's passed to a function which calls it indirectly.
I have no idea what's causing these to fail, but I at least have a slightly better idea
that could potentially be used to make a small test case.

[andlabs]

Comment 7:

Tried to strip out as much as possible from package ui while still exhibiting the error:
https://gist.github.com/anonymous/28e848db910f4c32c1e3
5 very small files, but any smaller and the error goes away :/

[ianlancetaylor]

Comment 8:

Thanks.  I assume you are putting all 5 files into the same directory and running "go
build".  Please run "go build -x" and show the complete output.
Also, what happens if you run "go build -ldflags -w"?

[gopherbot]

Comment 9 by [email protected]:

"go build" completes fine, it's linking with the resulting package that is the problem.
The reproduction gist above is for running with "go test".
Output for with and without "ldflags -w" is equal, the -x output suggests it's already
being passed without explicit mentioning.
Attached is the "go test -x" run, since the -w run has no differences.

Attachments:

1. x.txt (37744 bytes)

[alexbrainman]

Comment 10:

I think https://golang.org/issue/8811?c=7 is related to this too.
Alex

[alexbrainman]

Comment 11:

Please, review https://golang.org/cl/152410043 to see if that fixes your
problem. Thank you.
Alex

Status changed to Started.

[gopherbot]

Comment 12:

CL https://golang.org/cl/152410043 mentions this issue.

[alexbrainman]

Comment 13:

This issue was closed by revision d704bb0.

Status changed to Fixed.