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

slimsag · 2014-09-16T23:02:15Z

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 · 2014-09-16T23:04:32Z

Comment 1:

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

ianlancetaylor · 2014-09-17T00:03:13Z

Comment 2:

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

Status changed to Accepted.

rsc · 2014-09-26T19:53:23Z

Comment 3:

Issue #8702 has been merged into this issue.

rsc · 2014-09-26T19:57:07Z

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.

frederich · 2015-02-20T09:08:11Z

I'm working on it.

slimsag · 2015-02-20T09:12:17Z

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

frederich · 2015-02-20T09:35:00Z

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

steeve · 2015-02-20T15:50:38Z

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

rsc · 2015-06-08T06:10:50Z

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

alexbrainman · 2015-06-08T08:59:57Z

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

Alex

noblehng · 2015-06-26T02:36:03Z

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 · 2015-06-26T05:52:49Z

Yes it fails here for me too.

Alex

cpmech · 2016-05-03T12:56:22Z

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 · 2016-06-22T14:31:15Z

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 · 2016-06-23T01:22:18Z

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 · 2016-06-23T02:48:04Z

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 · 2016-06-23T06:28:05Z

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 · 2016-06-23T16:38:11Z

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

ianlancetaylor · 2016-06-23T16:38:55Z

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

Scratch-net · 2016-06-23T16:55:12Z

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 · 2016-06-23T17:55:46Z

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 · 2016-08-10T05:10:07Z

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

Alex

Scratch-net · 2016-08-10T06:38:32Z

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

alexbrainman · 2016-08-10T07:10:48Z

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 · 2016-08-10T07:13:33Z

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

alexbrainman · 2016-08-10T07:23:40Z

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 · 2016-08-10T07:30:09Z

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

cpmech · 2016-08-11T01:50:04Z

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

alexbrainman · 2016-08-11T01:58:18Z

It seems to work!

Thanks for checking.

Alex

cpmech · 2016-08-12T06:24:16Z

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 · 2016-10-24T13:23:28Z

@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 · 2016-10-24T15:18:59Z

@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 · 2016-10-25T04:37:01Z

@ianlancetaylor This patch fixes the second issue also

slimsag added accepted labels Sep 26, 2014

bradfitz modified the milestone: Go1.5 Dec 16, 2014

bradfitz removed the release-go1.5 label Dec 16, 2014

rsc added OS-Windows and removed os-windows labels Apr 10, 2015

rsc modified the milestones: Unplanned, Go1.5 Jun 8, 2015

rsc changed the title ~~cmd/ld: duplicate symbol reference pow on Windows~~ cmd/link: duplicate symbol reference pow on Windows Jun 8, 2015

alexbrainman mentioned this issue Jul 30, 2016

cmd/link: cgo build failed #16513

Closed

gopherbot closed this as completed in dfbbe06 Aug 31, 2016

xlab mentioned this issue Nov 1, 2016

Building doesn't work on Windows golang-ui/nuklear#2

Closed

golang locked and limited conversation to collaborators Oct 25, 2017

gopherbot added the FrozenDueToAge label Oct 25, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

slimsag commented Sep 16, 2014

slimsag commented Sep 16, 2014

ianlancetaylor commented Sep 17, 2014

rsc commented Sep 26, 2014

rsc commented Sep 26, 2014

frederich commented Feb 20, 2015

slimsag commented Feb 20, 2015

frederich commented Feb 20, 2015

steeve commented Feb 20, 2015

rsc commented Jun 8, 2015

alexbrainman commented Jun 8, 2015

noblehng commented Jun 26, 2015

alexbrainman commented Jun 26, 2015

cpmech commented May 3, 2016

Scratch-net commented Jun 22, 2016 •

edited

Loading

ianlancetaylor commented Jun 23, 2016

alexbrainman commented Jun 23, 2016

Scratch-net commented Jun 23, 2016 •

edited

Loading

ianlancetaylor commented Jun 23, 2016

ianlancetaylor commented Jun 23, 2016

Scratch-net commented Jun 23, 2016

ianlancetaylor commented Jun 23, 2016

alexbrainman commented Aug 10, 2016

Scratch-net commented Aug 10, 2016

alexbrainman commented Aug 10, 2016

Scratch-net commented Aug 10, 2016

alexbrainman commented Aug 10, 2016

Scratch-net commented Aug 10, 2016

cpmech commented Aug 11, 2016

alexbrainman commented Aug 11, 2016

cpmech commented Aug 12, 2016

shethchintan7 commented Oct 24, 2016

ianlancetaylor commented Oct 24, 2016

shethchintan7 commented Oct 25, 2016

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

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

Comments

slimsag commented Sep 16, 2014

slimsag commented Sep 16, 2014

ianlancetaylor commented Sep 17, 2014

rsc commented Sep 26, 2014

rsc commented Sep 26, 2014

frederich commented Feb 20, 2015

slimsag commented Feb 20, 2015

frederich commented Feb 20, 2015

steeve commented Feb 20, 2015

rsc commented Jun 8, 2015

alexbrainman commented Jun 8, 2015

noblehng commented Jun 26, 2015

alexbrainman commented Jun 26, 2015

cpmech commented May 3, 2016

Scratch-net commented Jun 22, 2016 • edited Loading

ianlancetaylor commented Jun 23, 2016

alexbrainman commented Jun 23, 2016

Scratch-net commented Jun 23, 2016 • edited Loading

ianlancetaylor commented Jun 23, 2016

ianlancetaylor commented Jun 23, 2016

Scratch-net commented Jun 23, 2016

ianlancetaylor commented Jun 23, 2016

alexbrainman commented Aug 10, 2016

Scratch-net commented Aug 10, 2016

alexbrainman commented Aug 10, 2016

Scratch-net commented Aug 10, 2016

alexbrainman commented Aug 10, 2016

Scratch-net commented Aug 10, 2016

cpmech commented Aug 11, 2016

alexbrainman commented Aug 11, 2016

cpmech commented Aug 12, 2016

shethchintan7 commented Oct 24, 2016

ianlancetaylor commented Oct 24, 2016

shethchintan7 commented Oct 25, 2016

Scratch-net commented Jun 22, 2016 •

edited

Loading

Scratch-net commented Jun 23, 2016 •

edited

Loading