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

Jump to bottom

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
Closed

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

andlabs opened this issue Oct 2, 2014 · 13 comments
Labels
FrozenDueToAge
Milestone
Go1.4

Comments

@andlabs
Copy link
Contributor

andlabs 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
Copy link
Contributor Author

andlabs 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
Copy link
Contributor Author

andlabs commented Oct 2, 2014

Comment 2:

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

@andlabs
Copy link
Contributor Author

andlabs 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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor Author

andlabs 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
Copy link
Contributor Author

andlabs 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
Copy link
Contributor

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
Copy link

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
Copy link
Member

Comment 10:

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

@alexbrainman
Copy link
Member

Comment 11:

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

Status changed to Started.

@gopherbot
Copy link

Comment 12:

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

@alexbrainman
Copy link
Member

Comment 13:

This issue was closed by revision d704bb0.

Status changed to Fixed.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
@alexbrainman @wheatman
cmd/ld: do not assume that only pe section names start with '.'
c8e8a2a 
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 pushed a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
@alexbrainman @wheatman
cmd/ld: do not assume that only pe section names start with '.'
c8b74bf 
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 pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
@alexbrainman @wheatman
cmd/ld: do not assume that only pe section names start with '.'
933b494 
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 pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
@alexbrainman @wheatman
cmd/ld: do not assume that only pe section names start with '.'
030fd8f 
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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.4
Development

No branches or pull requests
5 participants
@rsc @andlabs @ianlancetaylor @gopherbot @alexbrainman