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/6l: CGO program will only link with MinGW 4.8.1 on Windows #8811

Closed
slimsag opened this issue Sep 26, 2014 · 29 comments
Closed

cmd/6l: CGO program will only link with MinGW 4.8.1 on Windows #8811

slimsag opened this issue Sep 26, 2014 · 29 comments
Milestone

Comments

@slimsag
Copy link

slimsag commented Sep 26, 2014

I have tried the following Go versions:
* Tip
* Official Go 1.3.1 binaries.

What steps reproduce the problem?

1. Extract attached zip file (5 files, 47 lines in total) to $GOPATH/src/
2. cd $GOPATH/src/mingwbug
3. go build

What happened?

C:\Users\stephen\Desktop\godev\src\mingwbug>go build -a main.go
# command-line-arguments
mingwbug/glfw(.text): mingwbug/glfw(/76): not defined
mingwbug/glfw(.text): undefined: mingwbug/glfw(/76)

What should have happened instead?

The program should link.

Please provide any additional information below.

The program compiles, links, and runs fine when using MinGW 4.8.1.

If using MinGW 4.8.3 OR 4.9.1 (MinGW-W64 project or TDM-GCC) then the linker reports the
errors above.

This issue is a minimal example if the problem we ran into at
go-gl/glfw#91 if you want more information.
@slimsag
Copy link
Author

slimsag commented Sep 26, 2014

Comment 1:

(attachment)

Attachments:

  1. mingwbug.zip (1498 bytes)

@ianlancetaylor
Copy link
Contributor

Comment 2:

Please try running "go build -x" and report the results here so that we can see just
which command failed.  Thanks.

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

@slimsag
Copy link
Author

slimsag commented Sep 26, 2014

Comment 3:

The output is rather large? View it in full at http://pastebin.com/1niy3W2U
C:\Users\stephen\Desktop\godev\src\mingwbug>go build -x
...trimmed by me...
cd C:\Users\stephen\Desktop\godev\src\mingwbug
"C:\\tipgoamd64\\pkg\\tool\\windows_amd64\\6g.exe" -o
"C:\\Users\\stephen\\AppData\\Local\\Temp\\go-build954290891\\mingwbug.a" -t
rimpath "C:\\Users\\stephen\\AppData\\Local\\Temp\\go-build954290891" -p mingwbug
-complete -D _/C_/Users/stephen/Desktop/godev/sr
c/mingwbug -I "C:\\Users\\stephen\\AppData\\Local\\Temp\\go-build954290891" -I
"C:\\Users\\stephen\\Desktop\\godev\\pkg\\windows_a
md64" -pack "C:\\Users\\stephen\\Desktop\\godev\\src\\mingwbug\\main.go"
cd .
"C:\\tipgoamd64\\pkg\\tool\\windows_amd64\\6l.exe" -o
"C:\\Users\\stephen\\AppData\\Local\\Temp\\go-build954290891\\mingwbug\\_obj
\\exe\\a.out.exe" -L "C:\\Users\\stephen\\AppData\\Local\\Temp\\go-build954290891" -L
"C:\\Users\\stephen\\Desktop\\godev\\pkg\\wi
ndows_amd64" -extld=gcc
"C:\\Users\\stephen\\AppData\\Local\\Temp\\go-build954290891\\mingwbug.a"
# mingwbug
mingwbug/glfw(.text): mingwbug/glfw(/76): not defined
mingwbug/glfw(.text): undefined: mingwbug/glfw(/76)

@ianlancetaylor
Copy link
Contributor

Comment 4:

Sorry, I have no idea what is going on.  This is failing when running the Go linker on
Go code, so I can't see why changing the GCC version would make any difference.  I also
don't know what the "(/76)" is doing there.  This will have to be debugged by somebody
running Windows.

@rsc
Copy link
Contributor

rsc commented Oct 7, 2014

Comment 5:

Owner changed to @rsc.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Oct 7, 2014

Comment 6:

The form mingwbug/glfw(name) refers to the section name inside an object in
mingwbug/glfw. The name /76 is a PE-encoded string table reference, since they only
reserved 8 letters for the section name. 
$GOROOT/src/cmd/ld/ldpe.c needs to look for the /%d form of section name and do the
appropriate translation to the correct section name.

Labels changed: added release-go1.4, removed release-go1.4maybe.

Owner changed to ---.

@alexbrainman
Copy link
Member

Comment 7:

There are 2 problems here as far as I can see (in ldpe.c):
1) section names are not read properly - that is why we see /76 in mingwbug/glfw(/76),
/76 is a reference into "string table" where real name lives;
2) ldpe.c code assumes (in a few places) that all symbols with name starting with "."
are section names - this is broken now that new gcc starts some symbols with ".".
I am not familiar with that code enough to decide how to change it safely yet. But I
will keep looking.
Alex

@alexbrainman
Copy link
Member

Comment 8:

I had trouble finding latest gcc. http://nuwen.net/mingw.html is what I end-up using.
Alex

@andlabs
Copy link
Contributor

andlabs commented Oct 7, 2014

Comment 9:

@Alex: http://mingw-w64.sourceforge.net/ - on Windows the easiest way is to use the
mingw-builds distribution.

@gopherbot
Copy link
Contributor

Comment 10 by rich.amacker:

@Alex
Here's a 32-bit version:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/
Here's a 64-bit version:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/
If you go up to the parent folder, you'll find 4.8.1, 4.8.2, etc. as well.

@frederich
Copy link
Contributor

Comment 11:

I'll fix the issue.

@alexbrainman
Copy link
Member

Comment 12:

Sure, go ahead. I also have started on this issue. One of us will succeed. :-)
Alex

@frederich
Copy link
Contributor

Comment 13:

Oh sorry Alex, I've thought no one is on it. You can fix it if you want?
Jens

@alexbrainman
Copy link
Member

Comment 14:

No, please continue with your fix. I am not certain my solution is correct. Two heads
are better then one. Whoever is ready first will discuss during review.
Alex

@frederich
Copy link
Contributor

Comment 15:

ok

@frederich
Copy link
Contributor

Comment 16:

Interesting, there are more .rdata symbols on the 4.9.1 object file by the equivalent c
code.
e:\tmp>diff -uprN _cgo_export.o_good_481.sym _cgo_export.o_wrong_491.sym
--- _cgo_export.o_good_481.sym      Wed Oct 08 16:48:13 2014
+++ _cgo_export.o_wrong_491.sym     Wed Oct 08 16:47:11 2014
@@ -6,7 +6,9 @@
 0000000000000000 N .debug_info
 0000000000000000 N .debug_line
 0000000000000000 p .pdata
+0000000000000000 r .rdata$.refptr._cgoexp_9f48158d77e0_something
 0000000000000000 r .rdata$zzz
+0000000000000000 R .refptr._cgoexp_9f48158d77e0_something
 0000000000000000 t .text
 0000000000000000 r .xdata
                  U _cgoexp_9f48158d77e0_something
Jens

@frederich
Copy link
Contributor

Comment 17:

e:\tmp>diff -uprN two_good_481.sym two_wrong_491.sym
--- two_good_481.sym    Wed Oct 08 17:49:32 2014
+++ two_wrong_491.sym   Wed Oct 08 17:49:50 2014
@@ -7,7 +7,9 @@
 0000000000000000 N .debug_line
 0000000000000000 N .debug_str
 0000000000000000 p .pdata
+0000000000000000 r .rdata$.refptr._glfwInitialized
 0000000000000000 r .rdata$zzz
+0000000000000000 R .refptr._glfwInitialized
 0000000000000000 t .text
 0000000000000000 r .xdata
                  U _glfwInitialized
If I replace two.o and _cgo_export.o with the 4.8.1 versions and build all manually then
it will work. Now the question is: are the additional gcc .rdata sections wrong or has
the 6l.exe a bug and should handle it right?
Jens

@frederich
Copy link
Contributor

Comment 18:

I think https://golang.org/issue/8856 is related to.

@alexbrainman
Copy link
Member

Comment 19:

Yes 8856 is the same issue. I think.
Alex

@frederich
Copy link
Contributor

Comment 20:

I think https://golang.org/issue/8856 is related to this too.
Jens

@frederich
Copy link
Contributor

Comment 21:

That's the minimal setup to reproduce the issue.
Jens

Attachments:

  1. mingwbug5.zip (1055 bytes)

@frederich
Copy link
Contributor

Comment 22:

When there are at least two .refptr. sections in _all.o which depends on each other it
fails.
Jens

@gopherbot
Copy link
Contributor

Comment 23:

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

@alexbrainman
Copy link
Member

Comment 24:

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

Status changed to Started.

@gopherbot
Copy link
Contributor

Comment 25:

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

@frederich
Copy link
Contributor

Comment 26:

Alex, you've been faster. The CL LGTM and passes my tests.
Jens

@alexbrainman
Copy link
Member

Comment 27:

Thanks for review. I will wait for others.
Alex

@alexbrainman
Copy link
Member

Comment 28:

This issue was updated by revision d0ee959.

LGTM=iant, jfrederich
R=golang-codereviews, iant, jfrederich
CC=golang-codereviews
https://golang.org/cl/154210044

@alexbrainman
Copy link
Member

Comment 29:

This issue was closed by revision d704bb0.

Status changed to Fixed.

@slimsag slimsag added the fixed label Oct 11, 2014
@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label 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
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
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
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
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
Development

No branches or pull requests

7 participants