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

slimsag · 2014-09-26T04:04:57Z

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 · 2014-09-26T04:05:56Z

Comment 1:

(attachment)

Attachments:

mingwbug.zip (1498 bytes)

ianlancetaylor · 2014-09-26T04:48:09Z

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 · 2014-09-26T07:55:27Z

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 · 2014-09-26T13:29:04Z

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 · 2014-10-07T00:40:51Z

Comment 5:

Owner changed to @rsc.

Status changed to Accepted.

rsc · 2014-10-07T00:43:35Z

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 · 2014-10-07T01:16:34Z

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 · 2014-10-07T01:21:36Z

Comment 8:

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

andlabs · 2014-10-07T03:55:45Z

Comment 9:

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

gopherbot · 2014-10-07T21:10:19Z

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 · 2014-10-08T07:28:27Z

Comment 11:

I'll fix the issue.

alexbrainman · 2014-10-08T11:10:34Z

Comment 12:

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

frederich · 2014-10-08T12:14:54Z

Comment 13:

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

alexbrainman · 2014-10-08T12:17:46Z

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 · 2014-10-08T12:20:37Z

Comment 15:

ok

frederich · 2014-10-08T15:34:46Z

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 · 2014-10-08T15:58:06Z

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 · 2014-10-09T06:09:31Z

Comment 18:

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

alexbrainman · 2014-10-09T06:11:43Z

Comment 19:

Yes 8856 is the same issue. I think.
Alex

frederich · 2014-10-09T06:12:13Z

Comment 20:

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

frederich · 2014-10-09T14:46:16Z

Comment 21:

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

Attachments:

mingwbug5.zip (1055 bytes)

frederich · 2014-10-09T15:04:55Z

Comment 22:

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

gopherbot · 2014-10-09T23:41:09Z

Comment 23:

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

alexbrainman · 2014-10-10T00:45:29Z

Comment 24:

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

Status changed to Started.

gopherbot · 2014-10-10T00:46:29Z

Comment 25:

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

frederich · 2014-10-10T06:34:33Z

Comment 26:

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

alexbrainman · 2014-10-10T06:36:13Z

Comment 27:

Thanks for review. I will wait for others.
Alex

alexbrainman · 2014-10-11T10:34:24Z

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 · 2014-10-11T11:01:17Z

Comment 29:

This issue was closed by revision d704bb0.

Status changed to Fixed.

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

slimsag added the fixed label Oct 11, 2014

slimsag added repo-main labels Oct 11, 2014

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

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

golang locked and limited conversation to collaborators Jun 25, 2016

gopherbot added the FrozenDueToAge label Jun 25, 2016

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

slimsag commented Sep 26, 2014

slimsag commented Sep 26, 2014

ianlancetaylor commented Sep 26, 2014

slimsag commented Sep 26, 2014

ianlancetaylor commented Sep 26, 2014

rsc commented Oct 7, 2014

rsc commented Oct 7, 2014

alexbrainman commented Oct 7, 2014

alexbrainman commented Oct 7, 2014

andlabs commented Oct 7, 2014

gopherbot commented Oct 7, 2014

frederich commented Oct 8, 2014

alexbrainman commented Oct 8, 2014

frederich commented Oct 8, 2014

alexbrainman commented Oct 8, 2014

frederich commented Oct 8, 2014

frederich commented Oct 8, 2014

frederich commented Oct 8, 2014

frederich commented Oct 9, 2014

alexbrainman commented Oct 9, 2014

frederich commented Oct 9, 2014

frederich commented Oct 9, 2014

frederich commented Oct 9, 2014

gopherbot commented Oct 9, 2014

alexbrainman commented Oct 10, 2014

gopherbot commented Oct 10, 2014

frederich commented Oct 10, 2014

alexbrainman commented Oct 10, 2014

alexbrainman commented Oct 11, 2014

alexbrainman commented Oct 11, 2014

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

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

Comments

slimsag commented Sep 26, 2014

slimsag commented Sep 26, 2014

ianlancetaylor commented Sep 26, 2014

slimsag commented Sep 26, 2014

ianlancetaylor commented Sep 26, 2014

rsc commented Oct 7, 2014

rsc commented Oct 7, 2014

alexbrainman commented Oct 7, 2014

alexbrainman commented Oct 7, 2014

andlabs commented Oct 7, 2014

gopherbot commented Oct 7, 2014

frederich commented Oct 8, 2014

alexbrainman commented Oct 8, 2014

frederich commented Oct 8, 2014

alexbrainman commented Oct 8, 2014

frederich commented Oct 8, 2014

frederich commented Oct 8, 2014

frederich commented Oct 8, 2014

frederich commented Oct 9, 2014

alexbrainman commented Oct 9, 2014

frederich commented Oct 9, 2014

frederich commented Oct 9, 2014

frederich commented Oct 9, 2014

gopherbot commented Oct 9, 2014

alexbrainman commented Oct 10, 2014

gopherbot commented Oct 10, 2014

frederich commented Oct 10, 2014

alexbrainman commented Oct 10, 2014

alexbrainman commented Oct 11, 2014

alexbrainman commented Oct 11, 2014