cmd/6l: CGO program will only link with MinGW 4.8.1 on Windows
slimsag opened this issue · 29 comments
slimsag commented
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 commented
ianlancetaylor commented
slimsag commented
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 commented
rsc commented
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 commented
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 commented
I had trouble finding latest gcc. http://nuwen.net/mingw.html is what I end-up using. Alex
andlabs commented
@Alex: http://mingw-w64.sourceforge.net/ - on Windows the easiest way is to use the mingw-builds distribution.
gopherbot commented
@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 commented
alexbrainman commented
frederich commented
alexbrainman commented
frederich commented
frederich commented
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
Jensfrederich commented
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?
Jensfrederich commented
I think https://golang.org/issue/8856 is related to.
alexbrainman commented
frederich commented
I think https://golang.org/issue/8856 is related to this too. Jens
frederich commented
frederich commented
gopherbot commented
CL https://golang.org/cl/154210044 mentions this issue.
alexbrainman commented
Please, review https://golang.org/cl/152410043 to see if that fixes your problem. Thank you. Alex
Status changed to Started.
gopherbot commented
CL https://golang.org/cl/152410043 mentions this issue.
frederich commented
alexbrainman commented
alexbrainman commented
This issue was updated by revision d0ee959.
LGTM=iant, jfrederich R=golang-codereviews, iant, jfrederich CC=golang-codereviews https://golang.org/cl/154210044
alexbrainman commented