Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
andlabs opened this issue Oct 2, 2014 · 13 comments

Comments

@andlabs
Copy link
Contributor

commented Oct 2, 2014

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 2, 2014

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 2, 2014

Comment 2:

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 2, 2014

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

This comment has been minimized.

Copy link

commented Oct 2, 2014

Comment 4 by 2852914@wessie.info:

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

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2014

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 2, 2014

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2014

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

This comment has been minimized.

Copy link

commented Oct 6, 2014

Comment 9 by 2852914@wessie.info:

"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

This comment has been minimized.

Copy link
Member

commented Oct 7, 2014

Comment 10:

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

This comment has been minimized.

Copy link
Member

commented Oct 10, 2014

Comment 11:

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

Status changed to Started.

@gopherbot

This comment has been minimized.

Copy link

commented Oct 10, 2014

Comment 12:

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

This comment has been minimized.

Copy link
Member

commented Oct 11, 2014

Comment 13:

This issue was closed by revision d704bb0.

Status changed to Fixed.

@andlabs andlabs added fixed labels Oct 11, 2014

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015

@rsc rsc removed the release-go1.4maybe label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 25, 2016

wheatman added a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
cmd/ld: do not assume that only pe section names start with '.'
Our current pe object reader assumes that every symbol starting with
'.' is section. It appeared to be true, until now gcc 4.9.1 generates
some symbols with '.' at the front. Change that logic to check other
symbol fields in addition to checking for '.'. I am not an expert
here, but it seems reasonable to me.

Added test, but it is only good, if tested with gcc 4.9.1. Otherwise
the test PASSes regardless.

Fixes golang#8811.
Fixes golang#8856.

LGTM=jfrederich, iant, stephen.gutekanst
R=golang-codereviews, jfrederich, stephen.gutekanst, iant
CC=alex.brainman, golang-codereviews
https://golang.org/cl/152410043
wheatman added a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
cmd/ld: do not assume that only pe section names start with '.'
Our current pe object reader assumes that every symbol starting with
'.' is section. It appeared to be true, until now gcc 4.9.1 generates
some symbols with '.' at the front. Change that logic to check other
symbol fields in addition to checking for '.'. I am not an expert
here, but it seems reasonable to me.

Added test, but it is only good, if tested with gcc 4.9.1. Otherwise
the test PASSes regardless.

Fixes golang#8811.
Fixes golang#8856.

LGTM=jfrederich, iant, stephen.gutekanst
R=golang-codereviews, jfrederich, stephen.gutekanst, iant
CC=alex.brainman, golang-codereviews
https://golang.org/cl/152410043
wheatman added a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
cmd/ld: do not assume that only pe section names start with '.'
Our current pe object reader assumes that every symbol starting with
'.' is section. It appeared to be true, until now gcc 4.9.1 generates
some symbols with '.' at the front. Change that logic to check other
symbol fields in addition to checking for '.'. I am not an expert
here, but it seems reasonable to me.

Added test, but it is only good, if tested with gcc 4.9.1. Otherwise
the test PASSes regardless.

Fixes golang#8811.
Fixes golang#8856.

LGTM=jfrederich, iant, stephen.gutekanst
R=golang-codereviews, jfrederich, stephen.gutekanst, iant
CC=alex.brainman, golang-codereviews
https://golang.org/cl/152410043
wheatman added a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
cmd/ld: do not assume that only pe section names start with '.'
Our current pe object reader assumes that every symbol starting with
'.' is section. It appeared to be true, until now gcc 4.9.1 generates
some symbols with '.' at the front. Change that logic to check other
symbol fields in addition to checking for '.'. I am not an expert
here, but it seems reasonable to me.

Added test, but it is only good, if tested with gcc 4.9.1. Otherwise
the test PASSes regardless.

Fixes golang#8811.
Fixes golang#8856.

LGTM=jfrederich, iant, stephen.gutekanst
R=golang-codereviews, jfrederich, stephen.gutekanst, iant
CC=alex.brainman, golang-codereviews
https://golang.org/cl/152410043
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.