Hi minux,
one of those 3 CL's introduce a new CGO bug in Win64. As you probably
know, for // #cgo windows LDFLAGS the typical library lookup is
something like -lopengl32 -- should lookup \MinGW64\x86_64-w64-
mingw32\lib\libopengl32.a (in my %path% case) and \windows
\system32\opengl32.dll. However there is another gcc/ld syntax that
goes like this: -Wl,/dll64/opengl32.dll -- note the hard-coded
absolute file path including extension. (Why would I do this? Because
in Windows if a DLL is requested by a 32-bit process the 32-bit
version of the DLL is loaded from \windows\syswow64, if it is
requested by a 64-bit process, the 64-bit version of the DLL is loaded
from \windows\system32 -- I know, ironic that 64-bit ones are in
system32 and 32-bit ones are in syswow64, but this is not a typo. gcc
and ld are always 32-bit processes even in mingw64.)
So this is valid gcc/ld LDFLAGS syntax and also it works when doing a
"go build" on a package using this. For example, in my use-case a
modified version of package
https://github.com/chsc/gogl/blob/master/gl21/gl21.go
(the original works great under Linux and Win 32-bit).
So "go build" doesn't complain about this. But when I link such a
built package with a (pure GO) consumer package, a simple main.exe
console app, linking fails with the following warning:
malformed pe file: unexpected flags for PE section .idata$2
and then lots of "somefunc: not defined" linker errors.
(Now of course the 64-bit DLL according to file.exe is a "PE32+
executable for MS Windows (DLL) (console) Mono/.Net assembly" -- not
the classical "PE32 executable for MS Windows (DLL) (console) Intel
80386 32-bit" that 32-bit DLLs are described as -- .)
This does not happen in Go 1.0.1 without those 3 CLs applied. Though I
don't know which of those 3 CLs does this -- according to Google the
error message is produced in src/cmd/ld/ldpe.c.