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/link: duplicate symbol reference pow on Windows #8756

Closed
slimsag opened this issue Sep 16, 2014 · 33 comments
Closed

cmd/link: duplicate symbol reference pow on Windows #8756

slimsag opened this issue Sep 16, 2014 · 33 comments

Comments

@slimsag
Copy link

slimsag commented Sep 16, 2014

What does 'go version' print?
go version devel +ff82d3107ab3 Sun Aug 31 22:49:14 2014 -0400 windows/amd64

What steps reproduce the problem?

Create a program that uses math.h / pow function in two separate packages. Try to link
them together into one main program:

1. bug/bug.go: http://play.golang.org/p/nFkVRN6qN-
2. bug/one/one.go: http://play.golang.org/p/4e68AXsW1r
3. bug/two/two.go: http://play.golang.org/p/f3pNq-xniD
4. go install bug

What happened?
# bug
C:\Users\stephen\Desktop\godev\pkg\windows_amd64/bug/two.a(_all.o): duplicate symbol
reference: pow in both bug/one(.text) and bug/two(.text)

What should have happened instead?
The package should link properly.

Please provide any additional information below.

This is a simplified example of a bug I ran into recently. I have an application that
imports a CGO wrapper to the Chipmunk 2D physics engine and a CGO wrapper to GLFW. The
program links fine on Linux -- but I cannot build it on windows due to this issue.

FWIW I am using (TDM) MinGW-W64 4.8.1 rev2
@slimsag
Copy link
Author

slimsag commented Sep 16, 2014

Comment 1:

Possibly related to:
https://golang.org/issue/8702

@ianlancetaylor
Copy link
Contributor

Comment 2:

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

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Sep 26, 2014

Comment 3:

Issue #8702 has been merged into this issue.

@rsc
Copy link
Contributor

rsc commented Sep 26, 2014

Comment 4:

I'd love to fix this but it really requires having external linking support on Windows,
and that's not going to happen for 1.4.

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

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
@frederich
Copy link
Contributor

I'm working on it.

@slimsag
Copy link
Author

slimsag commented Feb 20, 2015

@frederich Can you clarify a bit? Working on getting 6l to accept it -- or working on external linking support on Windows?

@frederich
Copy link
Contributor

@slimsag look at @rsc comment above "It really requires having external linking support". I think this should be the goal.

@steeve
Copy link
Contributor

steeve commented Feb 20, 2015

That would be great, thanks for doing it.
That would fix #9095

@rsc rsc added OS-Windows and removed os-windows labels Apr 10, 2015
@rsc
Copy link
Contributor

rsc commented Jun 8, 2015

It should be easy to accept both undefined variables and variables declared as strings but nothing else.

@rsc rsc modified the milestones: Unplanned, Go1.5 Jun 8, 2015
@rsc rsc changed the title cmd/ld: duplicate symbol reference pow on Windows cmd/link: duplicate symbol reference pow on Windows Jun 8, 2015
@alexbrainman
Copy link
Member

@slimsag can you check to see if this is still broken on current tip? Thank you.

Alex

@noblehng
Copy link

It still doesn't work for me with external linker using git master.

What does 'go version' print?
go version devel +1045351 Thu Jun 25 07:05:07 2015 +0000 windows/amd64

What steps reproduce the problem?
The same as OP.

What happened?

D:\go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o: In function `_cgo_fe6e803f72a1_Cfunc_pow':
f:/code/cgo-windows-external-link/two/two.go:31: multiple definition of `_cgo_fe6e803f72a1_Cfunc_pow'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:f:/code/cgo-windows-external-link/one/one.go:31: first defined here
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o: In function `pow':
C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/math/pow.def.h:114: multiple definition of `pow'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/math/pow.def.h:114: first defined here
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o: In function `ldexp':
C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/math/ldexp.c:10: multiple definition of `ldexp'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/math/ldexp.c:10: first defined here
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o:C:\crossdev\gccmaster\build-tdm64\runtime\mingw-w64-crt/log2l.S:25: multiple definition of `log2l'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:C:\crossdev\gccmaster\build-tdm64\runtime\mingw-w64-crt/log2l.S:25: first defined here
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o:C:\crossdev\gccmaster\build-tdm64\runtime\mingw-w64-crt/exp2l.S:19: multiple definition of `exp2l'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:C:\crossdev\gccmaster\build-tdm64\runtime\mingw-w64-crt/exp2l.S:19: first defined here
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o: In function `__powi':
C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/math/powi.def.h:76: multiple definition of `__powi'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/math/powi.def.h:76: first defined here
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o: In function `__mingw_raise_matherr':
C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/crt/merr.c:16: multiple definition of `__mingw_raise_matherr'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/crt/merr.c:16: first defined here
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o: In function `__mingw_setusermatherr':
C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/crt/merr.c:32: multiple definition of `__mingw_setusermatherr'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/crt/merr.c:32: first defined here
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000001.o: In function `_matherr':
C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/crt/merr.c:38: multiple definition of `_matherr'
C:\Users\ADMINI~1\AppData\Local\Temp\go-link-548786811/000000.o:C:/crossdev/src/mingw-w64-v3-git/mingw-w64-crt/crt/merr.c:38: first defined here
collect2.exe: error: ld returned 1 exit status

What should have happened instead?
The package should link properly.

Please provide any additional information below.
I ran into this recently when trying to static linking libtiff and mozjpeg together with Go on windows.
Then I found this issue and tried Go 1.5 from git master. The new default external linking give out
above error message, and when forcing internal linking, the error message is the same as Go 1.4.2.

tdm64-gcc-4.9.2-3, msys+7za+wget+svn+git+mercurial+cvs-rev13 and mingw-w64-bin-x86_64-20150316(mingw-w64-dgn) were used.

@alexbrainman
Copy link
Member

Yes it fails here for me too.

Alex

@cpmech
Copy link

cpmech commented May 3, 2016

Hello,

I'd just like to report that this problem still happens in the latest go version (tip) with the code given in:
https://groups.google.com/forum/#!topic/golang-nuts/fW4KZQ05G_8

Cheers.
Dorival

@Scratch-net
Copy link

Scratch-net commented Jun 22, 2016

We have a similar issue

C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dekes01956.o):(.idata$5+0x0): multiple definition of `__imp_log'
C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dkpfs01140.o):(.idata$5+0x0): first defined here
C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dekes01934.o):(.idata$5+0x0): multiple definition of `__imp_ceil'
C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dkpfs01048.o):(.idata$5+0x0): first defined here
collect2.exe: error: ld returned 5 exit status

any suggested workarounds?

@ianlancetaylor
Copy link
Contributor

For mingw I think you are using the GNU linker. Try using -linkopt=-extldflags=--allow-multiple-definition.

The real fix may be to avoid adding -lmingwex -lmingw32 in cmd/go, and instead handle them as we do libgcc in loadlib in cmd/link/internal/lib.go.

@alexbrainman
Copy link
Member

The real fix may be to avoid adding -lmingwex -lmingw32 in cmd/go,

I agree.

I have been playing with this a while ago. The way I understand build process here (and you can read full gory details of cgo process in $GOROOT/src/cmd/cgo/doc.go), there are 2 steps: 1) each package (that is part of your final executable) is compiled into a compiled form (the bits that go into your $GOPATH/pkg directory); 2) final executable is built from all compiled packages.

When cmd/go runs steps 1, it calls gcc ... -lmingwex -lmingw32 ... to resolve all external symbols that you use in this package (pow in this case). This inserts machine code for pow into compiled package file, and it keeps "pow" as the function name.

So, when it is time to do step 2, the linker will discover that two different compiled packages have function with the same name (pow). It cannot have that.

I think what needs to happen is the "resolving pow symbol" bit should happen during step 2, not step 1.

You can stop "resolving pow symbol" during step 1 by removing "-lmingwex -lmingw32" parameters from that call above.

I am not sure how to add them during step 2. For "external" linking (the default mode), I think gcc will resolve symbols automatically (I had to revert https://go-review.googlesource.com/14472 to make "go test" pass in $GOROOT/misc/cgo/test - I still don't know why). For "internal" linking, I was toying with idea of calling gcc --print-file-name=libmingwex.a and gcc --print-file-name=libmingw32 .a and maybe all other external libs supplied via -l #cgo LDFLAGS and including all returned libraries into final link step. I suspect that is what Ian meant when he said "handle them as we do libgcc in loadlib in cmd/link/internal/lib.go".

any suggested workarounds?

I think, if you apply this:

diff --git a/src/cmd/go/build.go b/src/cmd/go/build.go
index 11a4eab..ddd5655 100644
--- a/src/cmd/go/build.go
+++ b/src/cmd/go/build.go
@@ -3286,7 +3286,7 @@ func (b *builder) cgo(p *Package, cgoExe, obj string, pcCFLAGS, pcLDFLAGS, cgofi
    if goos == "windows" {
        // libmingw32 and libmingwex have some inter-dependencies,
        // so must use linker groups.
-       staticLibs = []string{"-Wl,--start-group", "-lmingwex", "-lmingw32", "-Wl,--end-group"}
+       //staticLibs = []string{"-Wl,--start-group", "-lmingwex", "-lmingw32", "-Wl,--end-group"}
    }

    cflags := stringList(cgoCPPFLAGS, cgoCFLAGS)
diff --git a/src/runtime/cgo/cgo.go b/src/runtime/cgo/cgo.go
index ce0e6a3..1528f51 100644
--- a/src/runtime/cgo/cgo.go
+++ b/src/runtime/cgo/cgo.go
@@ -22,7 +22,7 @@ package cgo
 #cgo openbsd LDFLAGS: -lpthread
 // we must explicitly link msvcrt, because runtime needs ntdll, and ntdll
 // exports some incompatible libc functions. See golang.org/issue/12030.
-#cgo windows LDFLAGS: -lmsvcrt -lm -mthreads
+#cgo windows LDFLAGS: -lm -mthreads

 #cgo CFLAGS: -Wall -Werror

to the current tip, it will work for you. Assuming you are not doing anything fancy - for example, this will not work with "internal" linker.

Alex

@Scratch-net
Copy link

Scratch-net commented Jun 23, 2016

Recompiling go is not an option as we're trying to ship a production-ready library.
Also, as far as I see cgo uses link.exe instead of ld

go build -x "-ldflags=-extldflags "--allow-multiple-definition""  hello.go
...
"C:\\Go\\pkg\\tool\\windows_amd64\\link.exe" -o "c:\\Temp\\TotalCommanderPortableTemp\\go-build655578802\\command-line-arguments\\_obj\\exe\\a.out.exe" -L "c:\\Temp\\TotalCommanderPortableTemp\\go-build655578802" -L "d:\\Coding\\Go\\pkg\\windows_amd64" -extld=gcc -buildmode=exe -buildid=bd06eea3ebaeedc6769c8667312388544333b79c -extldflags --allow-multiple-definition "c:\\Temp\\TotalCommanderPortableTemp\\go-build655578802\\command-line-arguments.a"
# command-line-arguments
C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
gcc: error: unrecognized command line option '--allow-multiple-definition'

@ianlancetaylor
Copy link
Contributor

My apologies, it needs to be -linkopt=-extldflags=-Wl,--allow-multiple-definition.

@ianlancetaylor
Copy link
Contributor

By the way, yes, Go runs link.exe, but link.exe invokes gcc, and therefore the GNU linker, internally.

@Scratch-net
Copy link

Sorry, but where should I put -linkopt? Go build does not recognize it. My command line is now:
go build -x -ldflags "-extldflags=-Wl,--allow-multiple-definition" src\test\hello.go

and the output goes:

C:\gopath>go build -x -ldflags "-extldflags=-Wl,--allow-multiple-definition" src
\virgil_test\virgil_hello.go
WORK=C:\Users\Scratch\AppData\Local\Temp\go-build428278822
mkdir -p $WORK\virgil_crypto\_obj\
mkdir -p $WORK\
cd c:\gopath\src\virgil_crypto
CGO_LDFLAGS="-g" "-O2" "-Lc:/gopath/src/virgil_crypto/lib" "-lvirgil_crypto_go"
"-lvirgil_crypto" "-lmbedcrypto" "-led25519" "-lstdc++" "C:\\Go\\pkg\\tool\\wind
ows_amd64\\cgo.exe" -objdir "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build4
28278822\\virgil_crypto\\_obj\\" -importpath virgil_crypto -- -Ic:/gopath/src/vi
rgil_crypto/include -I "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278
822\\virgil_crypto\\_obj\\" virgil_crypto_go.go
gcc -I "c:\\gopath\\src\\virgil_crypto" -m64 -mthreads -fmessage-length=0 -Ic:/g
opath/src/virgil_crypto/include -I "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go
-build428278822\\virgil_crypto\\_obj\\" -g -O2 -o "C:\\Users\\Scratch\\AppData\\
Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\_cgo_main.o" -c "C:\\Users\
\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\_cgo_mai
n.c"
gcc -I "c:\\gopath\\src\\virgil_crypto" -m64 -mthreads -fmessage-length=0 -Ic:/g
opath/src/virgil_crypto/include -I "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go
-build428278822\\virgil_crypto\\_obj\\" -g -O2 -o "C:\\Users\\Scratch\\AppData\\
Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\_cgo_export.o" -c "C:\\User
s\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\_cgo_e
xport.c"
gcc -I "c:\\gopath\\src\\virgil_crypto" -m64 -mthreads -fmessage-length=0 -Ic:/g
opath/src/virgil_crypto/include -I "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go
-build428278822\\virgil_crypto\\_obj\\" -g -O2 -o "C:\\Users\\Scratch\\AppData\\
Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\virgil_crypto_go.cgo2.o" -c
 "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_crypto\\_o
bj\\virgil_crypto_go.cgo2.c"
gcc -I "c:\\gopath\\src\\virgil_crypto" -m64 -mthreads -fmessage-length=0 -o "C:
\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\
_cgo_.o" "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_cr
ypto\\_obj\\_cgo_main.o" "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build4282
78822\\virgil_crypto\\_obj\\_cgo_export.o" "C:\\Users\\Scratch\\AppData\\Local\\
Temp\\go-build428278822\\virgil_crypto\\_obj\\virgil_crypto_go.cgo2.o" -g -O2 -L
c:/gopath/src/virgil_crypto/lib -lvirgil_crypto_go -lvirgil_crypto -lmbedcrypto
-led25519 -lstdc++
"C:\\Go\\pkg\\tool\\windows_amd64\\cgo.exe" -objdir "C:\\Users\\Scratch\\AppData
\\Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\" -dynpackage virgil_cryp
to_go -dynimport "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\v
irgil_crypto\\_obj\\_cgo_.o" -dynout "C:\\Users\\Scratch\\AppData\\Local\\Temp\\
go-build428278822\\virgil_crypto\\_obj\\_cgo_import.go"
gcc -I "c:\\gopath\\src\\virgil_crypto" -m64 -mthreads -fmessage-length=0 -o "C:
\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\
_all.o" "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_cry
pto\\_obj\\_cgo_export.o" "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428
278822\\virgil_crypto\\_obj\\virgil_crypto_go.cgo2.o" -g -O2 -Lc:/gopath/src/vir
gil_crypto/lib -Wl,-r -nostdlib -Wl,--start-group -lmingwex -lmingw32 -Wl,--end-
group
"C:\\Go\\pkg\\tool\\windows_amd64\\compile.exe" -o "C:\\Users\\Scratch\\AppData\
\Local\\Temp\\go-build428278822\\virgil_crypto.a" -trimpath "C:\\Users\\Scratch\
\AppData\\Local\\Temp\\go-build428278822" -p virgil_crypto -buildid 5ed38eb7e4f5
15806b696ad86c678dcd16267bf7 -D _/c_/gopath/src/virgil_crypto -I "C:\\Users\\Scr
atch\\AppData\\Local\\Temp\\go-build428278822" -pack "C:\\Users\\Scratch\\AppDat
a\\Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\_cgo_gotypes.go" "C:\\Us
ers\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_crypto\\_obj\\virg
il_crypto_go.cgo1.go" "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build4282788
22\\virgil_crypto\\_obj\\_cgo_import.go"
pack r "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_cryp
to.a" "C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822\\virgil_crypt
o\\_obj\\_all.o" # internal
mkdir -p $WORK\command-line-arguments\_obj\
mkdir -p $WORK\command-line-arguments\_obj\exe\
cd C:\gopath\src\virgil_test
"C:\\Go\\pkg\\tool\\windows_amd64\\compile.exe" -o "C:\\Users\\Scratch\\AppData\
\Local\\Temp\\go-build428278822\\command-line-arguments.a" -trimpath "C:\\Users\
\Scratch\\AppData\\Local\\Temp\\go-build428278822" -p main -complete -buildid bd
06eea3ebaeedc6769c8667312388544333b79c -D _/C_/gopath/src/virgil_test -I "C:\\Us
ers\\Scratch\\AppData\\Local\\Temp\\go-build428278822" -I "c:\\gopath\\pkg\\wind
ows_amd64" -pack "C:\\gopath\\src\\virgil_test\\virgil_hello.go"
cd .
"C:\\Go\\pkg\\tool\\windows_amd64\\link.exe" -o "C:\\Users\\Scratch\\AppData\\Lo
cal\\Temp\\go-build428278822\\command-line-arguments\\_obj\\exe\\a.out.exe" -L "
C:\\Users\\Scratch\\AppData\\Local\\Temp\\go-build428278822" -L "c:\\gopath\\pkg
\\windows_amd64" -extld=gcc -buildmode=exe -buildid=bd06eea3ebaeedc6769c86673123
88544333b79c -extldflags=-Wl,--allow-multiple-definition "C:\\Users\\Scratch\\Ap
pData\\Local\\Temp\\go-build428278822\\command-line-arguments.a"
# command-line-arguments
C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w6
4-mingw32/bin/ld.exe: warning: C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-ming
w32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dekes01956.o): l
ocal symbol `☺' has no section
C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w6
4-mingw32/bin/ld.exe: warning: C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-ming
w32/5.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dekes01956.o): l
ocal symbol `♣' has no section
C:/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w6
4-mingw32/bin/ld.exe: BFD (GNU Binutils) 2.25 assertion fail ../../../src/binuti
ls-2.25/bfd/coff-x86_64.c:579
collect2.exe: error: ld returned 5 exit status

@ianlancetaylor
Copy link
Contributor

You are doing what I suggested; sorry for the flag name error. You are now running into a different problem. I don't know what that is or how to fix it. It seems that it must affect other non-Go mingw builds.

@alexbrainman
Copy link
Member

Whoever is still interested in fixing this, please test https://go-review.googlesource.com/#/c/26670/.
Thank you.

Alex

@Scratch-net
Copy link

@alexbrainman what's the chance of getting this into the next golang release?

@alexbrainman
Copy link
Member

what's the chance of getting this into the next golang release?

It won't be part of go1.7, because go1.7 is few days away.
It should be part of go1.8, if my change is accepted.

Does the change fixes your problem?

Alex

@Scratch-net
Copy link

I'm not sure how to test it. should I build the compiler by myself?

@alexbrainman
Copy link
Member

I'm not sure how to test it. should I build the compiler by myself?

You need to have Go install from source - see https://golang.org/doc/install/source for instructions.

Once you have Go git repo, you should go to https://go-review.googlesource.com/#/c/26670/ and click "Download" button in the right top corner, Copy long command listed next to "Checkout" into your clipboard. Paste the command into your command line (while you current directory is somewhere inside of Go repo). Run the command to update the source. Then rebuild Go again.

Alex

@Scratch-net
Copy link

Thanks. Not sure if I'll have time this week, but will try to test this some day

@cpmech
Copy link

cpmech commented Aug 11, 2016

Hey, It seems to work!
Thanks Alex!
I'll be writing about the test I did using Lapack in a moment...
Cheers

@alexbrainman
Copy link
Member

It seems to work!

Thanks for checking.

Alex

@cpmech
Copy link

cpmech commented Aug 12, 2016

Hello everyone,

I've prepared a GitHub Gist and a set of Videos illustrating the whole process from installing a C/Fortran based tool named LAPACK, it's connection with Go, the patching process, and the successful execution.

The issue (before the patch with Go1.6.3 on Windows) is illustrated here

After the patch, the code works as seen here

Thanks again Alex and everyone.
Cheers
Dorival

@shethchintan7
Copy link

@alexbrainman Any plans on this getting released? I am facing the same issue

C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dkbgs01971.o).idata$5+0x0): multiple definition of __imp_sqrt' C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dekes01190.o).idata$5+0x0): first defined here C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dkbgs01935.o).idata$5+0x0): multiple definition of__imp_cos' C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dekes01054.o).idata$5+0x0): first defined here C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dkbgs01971.o): illegal symbol index 116 in relocs

Adding //#cgo LDFLAGS: -Wl,--allow-multiple-definition resolved this but brought up something else

C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: warning:
C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dkbgs01971.o): local symbol ☻' has no sectionC:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: warning:C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dkbgs01971.o): local symbol☺' has no sectionC:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: warning:C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dkbgs01971.o): local symbol `♣' has no sectionC:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: BFD (GNUBinutils) 2.25 assertion fail ../../../src/binutils-2.25/bfd/coff-x86_64.c:579C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dkbgs01971.o): illegal symbol index 116 in relocs

Your patch worked perfectly fine. Any workarounds for this time being?

@ianlancetaylor
Copy link
Contributor

@shethchintan7 This issue is closed. The fix will be in the next Go release, 1.8, scheduled for February 1, 2017.

The first problem you mention should be fixed on tip. Please open a separate issue for the second problem. We will probably need a way to reproduce the error ourselves.

@shethchintan7
Copy link

@ianlancetaylor This patch fixes the second issue also

@golang golang locked and limited conversation to collaborators Oct 25, 2017
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