Cross-compiling for Windows using mingw and dll on linux

1,821 views
Skip to first unread message

rckc...@gmail.com

unread,
Jan 24, 2015, 4:40:54 AM1/24/15
to golan...@googlegroups.com
Hello,

I'm having a hard time getting a compile working.  The application compiles fine, but fails on (what I think is) linking.  Snipped output of go get -x . is:

...
/usr/src/go/pkg/tool/linux_amd64/8g -o $WORK/mingwtest.a -trimpath $WORK -p mingwtest -complete -D _/opt/go/src/mingwtest -I $WORK -I /opt/go/pkg/windows_386 -pack ./main.go
cd .
/usr/src/go/pkg/tool/linux_amd64/8l -o $WORK/mingwtest/_obj/exe/a.out.exe -L $WORK -L /opt/go/pkg/windows_386 -extld=i686-w64-mingw32-gcc $WORK/mingwtest.a
# mingwtest
github.com/op/go-libspotify/spotify(.text): sp_error_message: not defined
github.com/op/go-libspotify/spotify(.text): sp_album_add_ref: not defined
...

This builds and runs fine when done natively for linux.

I created a small project to reproduce this (using Docker for ease of reproducibility) at https://github.com/rckclmbr/mingwtest

I have exhausted my knowledge of the problem, and was hoping anyone could help me understand why these variables aren't defined.  Any help would be appreciated.

Thanks,
-Josh

Geovani de Souza

unread,
Jan 26, 2015, 5:25:08 AM1/26/15
to golan...@googlegroups.com
Have you tried Gox?

minux

unread,
Jan 26, 2015, 5:33:41 AM1/26/15
to rckc...@gmail.com, golang-nuts
On Sat, Jan 24, 2015 at 4:40 AM, <rckc...@gmail.com> wrote:
I'm having a hard time getting a compile working.  The application compiles fine, but fails on (what I think is) linking.  Snipped output of go get -x . is:

...
/usr/src/go/pkg/tool/linux_amd64/8g -o $WORK/mingwtest.a -trimpath $WORK -p mingwtest -complete -D _/opt/go/src/mingwtest -I $WORK -I /opt/go/pkg/windows_386 -pack ./main.go
cd .
/usr/src/go/pkg/tool/linux_amd64/8l -o $WORK/mingwtest/_obj/exe/a.out.exe -L $WORK -L /opt/go/pkg/windows_386 -extld=i686-w64-mingw32-gcc $WORK/mingwtest.a
# mingwtest
github.com/op/go-libspotify/spotify(.text): sp_error_message: not defined
github.com/op/go-libspotify/spotify(.text): sp_album_add_ref: not defined
...

This builds and runs fine when done natively for linux.
the problem is that the build couldn't find the correct libspotify.dll.

I took a brief look. I think your libspotify.pc is wrong:
Libs: -L${libdir} -llibspotify

It should use -lspotify instead.

Joshua Braegger

unread,
Jan 26, 2015, 11:27:20 AM1/26/15
to golan...@googlegroups.com, rckc...@gmail.com
Thanks for responding, Minux.

That's originally what I had (and it's probably correct), but I get a failure compiling if I do that.

CGO_LDFLAGS="-g" "-O2" "-L/libspotify/lib" "-lspotify" /usr/src/go/pkg/tool/linux_amd64/cgo -objdir $WORK/github.com/op/go-libspotify/spotify/_obj/ -- -I/libspotify/include -I $WORK/github.com/op/go-libspotify/spotify/_obj/ error.go libspotify.go
/usr/src/go/pkg/tool/linux_amd64/8c -F -V -w -trimpath $WORK -I $WORK/github.com/op/go-libspotify/spotify/_obj/ -I /usr/src/go/pkg/windows_386 -o $WORK/github.com/op/go-libspotify/spotify/_obj/_cgo_defun.8 -D GOOS_windows -D GOARCH_386 $WORK/github.com/op/go-libspotify/spotify/_obj/_cgo_defun.c
i686-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -print-libgcc-file-name
i686-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -I/libspotify/include -I $WORK/github.com/op/go-libspotify/spotify/_obj/ -g -O2 -o $WORK/github.com/op/go-libspotify/spotify/_obj/_cgo_main.o -c $WORK/github.com/op/go-libspotify/spotify/_obj/_cgo_main.c
i686-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -I/libspotify/include -I $WORK/github.com/op/go-libspotify/spotify/_obj/ -g -O2 -o $WORK/github.com/op/go-libspotify/spotify/_obj/_cgo_export.o -c $WORK/github.com/op/go-libspotify/spotify/_obj/_cgo_export.c
i686-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -I/libspotify/include -I $WORK/github.com/op/go-libspotify/spotify/_obj/ -g -O2 -o $WORK/github.com/op/go-libspotify/spotify/_obj/error.cgo2.o -c $WORK/github.com/op/go-libspotify/spotify/_obj/error.cgo2.c
i686-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -I/libspotify/include -I $WORK/github.com/op/go-libspotify/spotify/_obj/ -g -O2 -o $WORK/github.com/op/go-libspotify/spotify/_obj/libspotify.cgo2.o -c $WORK/github.com/op/go-libspotify/spotify/_obj/libspotify.cgo2.c
i686-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -I/libspotify/include -I $WORK/github.com/op/go-libspotify/spotify/_obj/ -g -O2 -o $WORK/github.com/op/go-libspotify/spotify/_obj/libspotify.o -c ./libspotify.c
/tmp/go-build055608681/github.com/op/go-libspotify/spotify/_obj/error.cgo2.o: In function `cgo_4738617973c1_Cfunc_sp_error_message':
../github.com/op/go-libspotify/spotify/error.go:52: undefined reference to `sp_error_message@4'
/tmp/go-build055608681/github.com/op/go-libspotify/spotify/_obj/libspotify.cgo2.o: In function `cgo_4738617973c1_Cfunc_sp_album_add_ref':
../github.com/op/go-libspotify/spotify/libspotify.go:126: undefined reference to `sp_album_add_ref@4'
/tmp/go-build055608681/github.com/op/go-libspotify/spotify/_obj/libspotify.cgo2.o: In function `cgo_4738617973c1_Cfunc_sp_album_artist':
../github.com/op/go-libspotify/spotify/libspotify.go:139: undefined reference to `sp_album_artist@4'

-Josh

Joshua Braegger

unread,
Jan 26, 2015, 12:56:09 PM1/26/15
to golan...@googlegroups.com
Ok, I can reproduce this using C, and have a workaround, but am still wondering why the build is failing.  Here is my C code:

#include <stdio.h>
#include <libspotify/api.h>

int main() {
    const char* error_message = sp_error_message(SP_ERROR_BAD_API_VERSION);
    printf("Success: %s\n", strcmp(error_message, "Invalid library version") == 0
                                ? "true" : "false");
    return 0;
}

Compile using gcc/linux is fine:

$ gcc -o test test.c -lspotify && ./test
Success: true

Compile using ming fails:

$ i686-w64-mingw32-gcc -o test.exe test.c -lspotify
/tmp/cceANomQ.o:test.c:(.text+0x1e): undefined reference to `sp_error_message@4'
collect2: error: ld returned 1 exit status

If I use -llibspotify, it compiles are runs fine:

i686-w64-mingw32-gcc -o test.exe test.c -llibspotify && wine test.exe
Success: true

So , is the c compilation (ming) expecting it in format "-llibspotify", but some other point in go compilation expects it as "-lspotify"?  If so, how can 

-Josh

Dave Cheney

unread,
Jan 27, 2015, 6:24:56 AM1/27/15
to golan...@googlegroups.com
Have you tried

// #cgo LDFLAGS: -lspotify

Joshua Braegger

unread,
Jan 28, 2015, 1:16:13 AM1/28/15
to golan...@googlegroups.com
I've tried what you've suggested Dave, to no avail.  

I'm seeing a compile flag that's actually missing libspotify, which I'm wondering if it's a problem with the go build toolchain.

What's interesting to me is in the build, this command is run:

i686-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -o $WORK/mingwtest/_obj/_all.o $WORK/mingwtest/_obj/_cgo_export.o $WORK/mingwtest/_obj/main.cgo2.o -g -O2 -L/libspotify/lib -Wl,-r -nostdlib -Wl,--start-group -lmingwex -lmingw32 -Wl,--end-group /usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc.a

What you'll notice is that that the libspotify lib path is included (-L/libspotify/lib), but no -lspotify.  I manually compiled using the output of "go build -n" (and had to compile a packer, based on go's internal packer in go/cmd/go/build.go packInternal).  I added "-lspotify" to the above command, and the code compiles fine (this seems like bug #1)

When running the compiled file in wine, I get a panic:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x40103b]

goroutine 1 [running]:
main._Cfunc_sp_error_message(0x1, 0x0)
mingwtest/_obj/_cgo_gotypes.go:29 +0x3b
main.main()
/opt/go/src/mingwtest/main.go:12 +0x29

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/src/go/src/runtime/asm_386.s:2287 +0x1

where main.go:12 is the line that calls "C.sp_error_message".  So basically, the executable has no information about the dynamic link to libspotify.dll.

Looking at the 8l command, 1) it's passing -extld=i686-w64-mingw32-gcc, which isn't used for windows (if I set '-linkmode=external' I get the message 'cannot use -linkmode=external with -H windows'). and 2) it's not using '-extldflags="-lspotify"', which I would think it would need to reference the dll.

I would really love some help to get this to compile in windows.  Also, am I wasting my time cross-compiling, and this should "just work" by compiling directly on windows?

-Josh

Dave Cheney

unread,
Jan 28, 2015, 3:57:39 AM1/28/15
to golan...@googlegroups.com
I think you should compile natively on windows, its a shorter and better trodden path to a solution.

Joshua Braegger

unread,
Jan 28, 2015, 12:41:03 PM1/28/15
to golan...@googlegroups.com
I tried building on Windows, and receive the same error message:

main(.text): sp_error_message: not defined
main(.text): undefined: sp_error_message


Complete output:

PS C:\Users\josh\mingwtest> go build -x -work .
WORK
=C:\Users\josh\AppData\Local\Temp\go-build935999867
mkdir
-p $WORK\_\C_\Users\josh\mingwtest\_obj\
cd C
:\Users\josh\mingwtest
pkg
-config --cflags libspotify
pkg
-config --libs libspotify
CGO_LDFLAGS
="-g" "-O2" "-L/libspotify/lib" "-lspotify" "C:\\Go\\pkg\\tool\\windows_386\\cgo.exe" -objdir "C:\\Users\\jos
h\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\"
-- -I/libspotify/include -I "C:\\User
s\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\"
main.go
"C:\\Go\\pkg\\tool\\windows_386\\8c.exe" -F -V -w -trimpath "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867" -
I
"C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\" -I "C:\\Go\\pkg\\win
dows_386"
-o "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_defun.
8"
-D GOOS_windows -D GOARCH_386 "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtes
t\\_obj\\_cgo_defun.c"

gcc
-I "C:\\Users\\josh\\mingwtest" -m32 -mthreads -fmessage-length=0 -print-libgcc-file-name
gcc
-I "C:\\Users\\josh\\mingwtest" -m32 -mthreads -fmessage-length=0 -I/libspotify/include -I "C:\\Users\\josh\\AppData
\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\"
-g -O2 -o "C:\\Users\\josh\\AppData\\Local\\Tem
p\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_main.o"
-c "C:\\Users\\josh\\AppData\\Local\\Temp\\go-bu
ild935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_main.c"

gcc
-I "C:\\Users\\josh\\mingwtest" -m32 -mthreads -fmessage-length=0 -I/libspotify/include -I "C:\\Users\\josh\\AppData
\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\"
-g -O2 -o "C:\\Users\\josh\\AppData\\Local\\Tem
p\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_export.o"
-c "C:\\Users\\josh\\AppData\\Local\\Temp\\go-
build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_export.c"

gcc
-I "C:\\Users\\josh\\mingwtest" -m32 -mthreads -fmessage-length=0 -I/libspotify/include -I "C:\\Users\\josh\\AppData
\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\"
-g -O2 -o "C:\\Users\\josh\\AppData\\Local\\Tem
p\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\main.cgo2.o"
-c "C:\\Users\\josh\\AppData\\Local\\Temp\\go-bu
ild935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\main.cgo2.c"

gcc
-I "C:\\Users\\josh\\mingwtest" -m32 -mthreads -fmessage-length=0 -o "C:\\Users\\josh\\AppData\\Local\\Temp\\go-buil
d935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_.o"
"C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\
C_\\Users\\josh\\mingwtest\\_obj\\_cgo_main.o"
"C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\
josh\\mingwtest\\_obj\\_cgo_export.o"
"C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\min
gwtest\\_obj\\main.cgo2.o"
-g -O2 -L/libspotify/lib -lspotify
"C:\\Go\\pkg\\tool\\windows_386\\cgo.exe" -objdir "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\User
s\\josh\\mingwtest\\_obj\\"
-dynimport "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mi
ngwtest\\_obj\\_cgo_.o"
-dynout "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest
\\_obj\\_cgo_import.c"

"C:\\Go\\pkg\\tool\\windows_386\\8c.exe" -F -V -w -trimpath "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867" -
I
"C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\" -I "C:\\Go\\pkg\\win
dows_386"
-o "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_import
.8"
-D GOOS_windows -D GOARCH_386 "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwte
st\\_obj\\_cgo_import.c"

gcc
-I "C:\\Users\\josh\\mingwtest" -m32 -mthreads -fmessage-length=0 -o "C:\\Users\\josh\\AppData\\Local\\Temp\\go-buil
d935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_all.o"
"C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C
_\\Users\\josh\\mingwtest\\_obj\\_cgo_export.o"
"C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\
\josh\\mingwtest\\_obj\\main.cgo2.o"
-g -O2 -L/libspotify/lib -Wl,-r -nostdlib -Wl,--start-group -lmingwex -lmingw32 -Wl
,--end-group "C:/Program Files (x86)/mingw-w64/i686-4.9.2-posix-dwarf-rt_v3-rev1/mingw32/bin/../lib/gcc/i686-w64-mingw32
/4.9.2/libgcc.a"

"C:\\Go\\pkg\\tool\\windows_386\\8g.exe" -o "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\jos
h\\mingwtest.a"
-trimpath "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867" -p _/C_/Users/josh/mingwtest -D _/C
_
/Users/josh/mingwtest -I "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867" -pack "C:\\Users\\josh\\AppData\\Lo
cal\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_gotypes.go"
"C:\\Users\\josh\\AppData\\Local\\Te
mp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\main.cgo1.go"

pack r
"C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest.a" "C:\\Users\\josh\\App
Data\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_import.8"
"C:\\Users\\josh\\AppData\\Loc
al\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_cgo_defun.8"
"C:\\Users\\josh\\AppData\\Local\\Temp\\
go-build935999867\\_\\C_\\Users\\josh\\mingwtest\\_obj\\_all.o"
# internal
cd
.
"C:\\Go\\pkg\\tool\\windows_386\\8l.exe" -o mingwtest.exe -L "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867"
-extld=gcc "C:\\Users\\josh\\AppData\\Local\\Temp\\go-build935999867\\_\\C_\\Users\\josh\\mingwtest.a"
# _/C_/Users/josh/mingwtest
main
(.text): sp_error_message: not defined
main
(.text): undefined: sp_error_message


So is linking just broken on Windows?

-Josh

Konstantin Khomoutov

unread,
Jan 28, 2015, 1:51:07 PM1/28/15
to Joshua Braegger, golan...@googlegroups.com
On Wed, 28 Jan 2015 09:41:02 -0800 (PST)
Joshua Braegger <rckc...@gmail.com> wrote:

> I tried building on Windows, and receive the same error message:
>
> main(.text): sp_error_message: not defined
> main(.text): undefined: sp_error_message
>
>
> Complete output:
>
> PS C:\Users\josh\mingwtest> go build -x -work .
> WORK=C:\Users\josh\AppData\Local\Temp\go-build935999867
> mkdir -p $WORK\_\C_\Users\josh\mingwtest\_obj\
> cd C:\Users\josh\mingwtest
> pkg-config --cflags libspotify
> pkg-config --libs libspotify
> CGO_LDFLAGS="-g" "-O2" "-L/libspotify/lib" "-lspotify"
[...]
> main(.text): sp_error_message: not defined
> main(.text): undefined: sp_error_message
>
>
> So is linking just broken on Windows?

Can you verify the libspotify library does indeed export the symbol
"sp_error_message"?

Use something like

nm -e ..\path\to\libspotify.a | grep error_message

Joshua Braegger

unread,
Jan 28, 2015, 2:28:24 PM1/28/15
to golan...@googlegroups.com, rckc...@gmail.com
This is windows, but yep the dll exports it:

$ wine dumpbin/dumpbin.exe /exports /symbols dll/libspotify.dll | fgrep error_message
         
47   2E 000E3110 _sp_error_message@4

The libspotify.lib references it correctly as well:

$ nm dll/libspotify.lib | grep -b6 error_message
10333-
10334-libspotify.dll:
10350-00000000 I .idata$4
10370-00000000 I .idata$5
10390-00000000 I .idata$6
10410-         U __IMPORT_DESCRIPTOR_libspotify
10452:00000000 I __imp__sp_error_message@4
10489:00000000 T _sp_error_message@4
10520-00000000 T .text
10537-
10538-libspotify.dll:
10554-00000000 I .idata$4
10574-00000000 I .idata$5
10594-00000000 I .idata


-Josh

Konstantin Khomoutov

unread,
Jan 28, 2015, 2:46:53 PM1/28/15
to Joshua Braegger, golan...@googlegroups.com
On Wed, 28 Jan 2015 11:28:24 -0800 (PST)
Joshua Braegger <rckc...@gmail.com> wrote:

> This is windows, but yep the dll exports it:
>
> $ wine dumpbin/dumpbin.exe /exports /symbols dll/libspotify.dll |
> fgrep error_message
> 47 2E 000E3110 _sp_error_message@4
>
> The libspotify.lib references it correctly as well:
>
> $ nm dll/libspotify.lib | grep -b6 error_message
> 10333-
> 10334-libspotify.dll:
> 10350-00000000 I .idata$4
> 10370-00000000 I .idata$5
> 10390-00000000 I .idata$6
> 10410- U __IMPORT_DESCRIPTOR_libspotify
> 10452:00000000 I __imp__sp_error_message@4
> 10489:00000000 T _sp_error_message@4

No time to dig deeper right now but [1] seems to be fishy on
all those "_" prefixes and "@<n>" suffixes.

1. http://www.mingw.org/wiki/createimportlibraries

minux

unread,
Jan 29, 2015, 4:12:22 AM1/29/15
to Joshua Braegger, golang-nuts
On Wed, Jan 28, 2015 at 1:16 AM, Joshua Braegger <rckc...@gmail.com> wrote:
I've tried what you've suggested Dave, to no avail.  

I'm seeing a compile flag that's actually missing libspotify, which I'm wondering if it's a problem with the go build toolchain.

What's interesting to me is in the build, this command is run:

i686-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -o $WORK/mingwtest/_obj/_all.o $WORK/mingwtest/_obj/_cgo_export.o $WORK/mingwtest/_obj/main.cgo2.o -g -O2 -L/libspotify/lib -Wl,-r -nostdlib -Wl,--start-group -lmingwex -lmingw32 -Wl,--end-group /usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc.a

What you'll notice is that that the libspotify lib path is included (-L/libspotify/lib), but no -lspotify.  I manually compiled using the output of "go build -n" (and had to compile a packer, based on go's internal packer in go/cmd/go/build.go packInternal).  I added "-lspotify" to the above command, and the code compiles fine (this seems like bug #1)
This is not a bug. _all.o is not supposed to link to external dynamic libraries.
(Actually if you link the DLL in this step, it will cause the final linking to omit
the DLL in the final binary's import table, and cause the error you saw.)

minux

unread,
Jan 29, 2015, 4:14:16 AM1/29/15
to Joshua Braegger, golang-nuts
On Wed, Jan 28, 2015 at 2:28 PM, Joshua Braegger <rckc...@gmail.com> wrote:
This is windows, but yep the dll exports it:

$ wine dumpbin/dumpbin.exe /exports /symbols dll/libspotify.dll | fgrep error_message
         
47   2E 000E3110 _sp_error_message@4

The libspotify.lib references it correctly as well:
mingw doesn't use the stubs from *.lib. It can generate them on the fly.

Have you tried listing the (full) path to DLL explicitly on cgo LDFLAGS?

Joshua Braegger

unread,
Jan 29, 2015, 1:45:34 PM1/29/15
to golan...@googlegroups.com, rckc...@gmail.com
Are you sure mingw can generate them on the fly?  I get the following error:

CGO_LDFLAGS="-g" "-O2" "/libspotify/lib/libspotify.dll" /usr/src/go/pkg/tool/linux_amd64/cgo -objdir $WORK/mingwtest/_obj/ -- -I $WORK/mingwtest/_obj/ -I /libspotify/include main.go
/usr/src/go/pkg/tool/linux_amd64/8c -F -V -w -trimpath $WORK -I $WORK/mingwtest/_obj/ -I /usr/src/go/pkg/windows_386 -o $WORK/mingwtest/_obj/_cgo_defun.8 -D GOOS_windows -D GOARCH_386 $WORK/mingwtest/_obj/_cgo_defun.c
i686
-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -print-libgcc-file-name
i686
-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -I $WORK/mingwtest/_obj/ -g -O2 -I /libspotify/include -o $WORK/mingwtest/_obj/_cgo_main.o -c $WORK/mingwtest/_obj/_cgo_main.c
i686
-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -I $WORK/mingwtest/_obj/ -g -O2 -I /libspotify/include -o $WORK/mingwtest/_obj/_cgo_export.o -c $WORK/mingwtest/_obj/_cgo_export.c
i686
-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -I $WORK/mingwtest/_obj/ -g -O2 -I /libspotify/include -o $WORK/mingwtest/_obj/main.cgo2.o -c $WORK/mingwtest/_obj/main.cgo2.c
i686
-w64-mingw32-gcc -I . -m32 -mthreads -fmessage-length=0 -o $WORK/mingwtest/_obj/_cgo_.o $WORK/mingwtest/_obj/_cgo_main.o $WORK/mingwtest/_obj/_cgo_export.o $WORK/mingwtest/_obj/main.cgo2.o -g -O2 /libspotify/lib/libspotify.dll
# mingwtest
/tmp/go-build953975252/mingwtest/_obj/main.cgo2.o: In function `cgo_de2ec629320b_Cfunc_sp_error_message':
./main.go:39: undefined reference to `
sp_error_message@4'

I created a test c file just to be sure it wasn't working with ming (https://github.com/rckclmbr/mingwtest/blob/master/c_test/test.c) and it fails as well:

$ i686-w64-mingw32-gcc -I/libspotify/include -m32 -o test.exe test.c /libspotify/lib/libspotify.dll
/tmp/cclqGZmV.o:test.c:(.text+0x1e): undefined reference to `sp_error_message@4'

collect2: error: ld returned 1 exit status

However, using the the lib works fine:

$ i686-w64-mingw32-gcc -I/libspotify/include -m32 -o test.exe test.c /libspotify/lib/libspotify.lib
$ wine test
.exe
Success: true

I tried specifying the absolute path to the lib in the cgo application yields the following (albeit different) error message:

...
pack r $WORK
/mingwtest.a $WORK/mingwtest/_obj/_cgo_import.8 $WORK/mingwtest/_obj/_cgo_defun.8 $WORK/mingwtest/_obj/_all.o # internal
cd
.
/usr/src/go/pkg/tool/linux_amd64/8l -o $WORK/mingwtest/_obj/exe/a.out.exe -L $WORK -extld=i686-w64-mingw32-gcc $WORK/mingwtest.a
# mingwtest
/tmp/go-build284869168/mingwtest.a(_all.o): malformed pe file: unexpected flags 0xe0500020 for PE section .text
main
._cgo_231fbd32956b_Cfunc_sp_error_message: _cgo_231fbd32956b_Cfunc_sp_error_message: not defined
main
._cgo_231fbd32956b_Cfunc_sp_error_message: undefined: _cgo_231fbd32956b_Cfunc_sp_error_message

Checking mingwtest.a, it does in fact reference _cgo_231fbd32956b_Cfunc_sp_error_message:

$ nm $WORK/mingwtest.a
nm
: __.PKGDEF: File format not recognized
nm
: _go_.8: File format not recognized
nm
: _cgo_import.8: File format not recognized
nm
: _cgo_defun.8: File format not recognized


_all
.o:
00000000 b .bss
00000000 b .bss
00000000 d .data
00000000 d .data
00000000 N .debug_abbrev
00000019 N .debug_abbrev
00000000 N .debug_aranges
00000018 N .debug_aranges
00000000 N .debug_frame
00000000 N .debug_info
0000015f N .debug_info
00000000 N .debug_line
0000001d N .debug_line
00000000 N .debug_loc
00000000 N .debug_str
00000000 i .idata$2
         U
.idata$4
00000004 i .idata$4
00000004 i .idata$5
00000004 i .idata$5
00000010 i .idata$6
00000000 i .idata$6
00000014 r .rdata$zzz
00000000 r .rdata$zzz
00000000 t .text
00000000 t .text
00000040 t .text
009c766f a @comp.id
009c766f a @comp.id
009c766f a @comp.id
00000000 I __IMPORT_DESCRIPTOR_libspotify
00000000 I __NULL_IMPORT_DESCRIPTOR
00000000 T __cgo_231fbd32956b_Cfunc_sp_error_message
         U __cgo_topofstack
00000004 I __imp__sp_error_message@4
00000040 T _sp_error_message@4
00000000 I libspotify_NULL_THUNK_DATA

Joshua Braegger

unread,
Feb 5, 2015, 12:48:59 AM2/5/15
to golan...@googlegroups.com, rckc...@gmail.com
I haven't been able to get anywhere on this.  Does anyone have any idea what's going on?

-Josh

...

eder.be...@gmail.com

unread,
Feb 14, 2015, 8:51:37 AM2/14/15
to golan...@googlegroups.com
Is there any solution for this problem?
Since this would be truly essential software for so many GMAA-users, the developer really deserves support!

Am Samstag, 24. Januar 2015 10:40:54 UTC+1 schrieb Joshua Braegger:
Hello,

I'm having a hard time getting a compile working.  The application compiles fine, but fails on (what I think is) linking.  Snipped output of go get -x . is:

...

Reply all
Reply to author
Forward
0 new messages