Open jclc opened 5 years ago
https://github.com/andlabs/ui/issues/326#issuecomment-426847357
Apparently some linker flags are lost in the ether when including both packages. Appending -lole32 -loleaut32 -limm32 -lversion
to CGO_LDFLAGS
fixes this issue.
Hi @jclc, does that mean the ui
package is the one that requires the extra link libraries?
The error message is triggered by SDL2, so I would imagine that it's an SDL2 issue. Adding these linker flags as a CGO directive would probably fix it, but I'd like to know the root cause of it.
It seems some people experienced it because they were compiling statically or have only static SDL2 library in their paths. Maybe it's because the ui
package compiles with -static
option?
You're right, it seems that SDL2 is now linked statically... that's not good. ui
being linked statically shouldn't affect SDL2, so I believe this is an issue with Go.
Perhaps you could try compiling the program via go get -tags static
and go build -tags static
? We had support for static build since 0.3 (thanks gen2brain!).
Yeah that's the thing though, ui
seems to force static linking on SDL2 which I don't want. Also, the error comes from g++ for some reason. ui
uses C++ on Windows and it's also forcing SDL2 to use it as well, I don't think that's intended.
It should still be possible to dynamically link SDL2 even with package ui; that's weird. I'll have to look at the build tags of this package...
The C++ linker should not affect anything. If SDL is affected by it, then we have a problem with SDL...
Returning to my project after a while, I'm finding more linker flags being lost.
/usr/local/go/pkg/tool/linux_amd64/link: running x86_64-w64-mingw32-g++ failed: exit status 1
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libSDL2.a(hid.o):(.text+0x382): undefined reference to `__imp_SetupDiGetClassDevsA'
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libSDL2.a(hid.o):(.text+0x391): undefined reference to `__imp_SetupDiGetDeviceRegistryPropertyA'
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libSDL2.a(hid.o):(.text+0x3e0): undefined reference to `__imp_SetupDiEnumDeviceInterfaces'
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libSDL2.a(hid.o):(.text+0x40d): undefined reference to `__imp_SetupDiGetDeviceInterfaceDetailA'
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libSDL2.a(hid.o):(.text+0x445): undefined reference to `__imp_SetupDiGetDeviceInterfaceDetailA'
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libSDL2.a(hid.o):(.text+0x456): undefined reference to `__imp_SetupDiEnumDeviceInfo'
/usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/lib/../lib/libSDL2.a(hid.o):(.text+0x585): undefined reference to `__imp_SetupDiDestroyDeviceInfoList'
Adding -lsetupapi
fixes this error. I'm not sure if upgrading mingw or SDL2 triggered this. Again, this only happens when importing both go-sdl2 and ui in the same program.
Edit: Right, it's because Go is forcing static linking but without the static
tag, so the LDFLAGS in sdl/sdl_cgo_static.go
are being omitted. -lsetupapi
was added in the most recent commit. Maybe a more appropriate name for this issue is "importing github.com/andlabs/ui forces static linking".
Right; I've taken steps to allow libui to be statically linkable specifically to make it more Go-like in nature; the interplay between this and that is an interesting question, and one that's in scope for the next release. Please file a bug there so I can keep track of it.
Are you sure it's an issue with libui though? I have no issues importing both ui and https://github.com/mattn/go-sqlite3; only go-sdl2 seems to have this issue.
FYI the code I'm using to test this:
package main
import (
_ "github.com/andlabs/ui"
_ "github.com/mattn/go-sqlite3"
// _ "github.com/veandco/go-sdl2/sdl"
"fmt"
)
func main() {
fmt.Println("ok")
}
CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ GOOS=windows go build main.go
Hi @jclc, I'll have a look at this as well during the weekend. I'll keep you posted!
It's not so much a problem with libui but a subtlety with mixing packages that expect different linking requirements. My question is about what's conventional for the rest of the Go open-source world, so I can provide the best possible solution. libui can be used dynamically and it would be great if I could provide that option as well...
Hi @jclc, do you have problem when compiling with -tags static
like this?
CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ GOOS=windows go build -tags static
I can't seem to reproduce the problem on my Linux OS with this code:
package main
import (
_ "github.com/andlabs/ui"
_ "github.com/mattn/go-sqlite3"
_ "github.com/veandco/go-sdl2/sdl"
"fmt"
)
func main() {
fmt.Println("ok")
}
With https://github.com/veandco/go-sdl2/commit/d969945fa22d438e43c81c992cd4243d5278be05 that works, but only when using -tags static
. The problem was linking ui statically but sdl dynamically.
@jclc Ahh I see now! You're cross-compiling on Linux to Windows but require SDL2 to be dynamic.
In that case, could you try modifying sdl/sdl_cgo.go
by replacing the #cgo windows ...
line to this?
//#cgo windows LDFLAGS: -Wl, -Bdynamic -lSDL2
For me, I had to specify include path as well like the following. Perhaps you also need it.
//#cgo windows LDFLAGS: -Wl, -Bdynamic -lSDL2 -L [path-to-lib-dir]
I haven't tried to run it but at least it compiled for me =P
@veeableful Hi, sorry for the delay, I've been busy. What version of Go are you using? For me it says those flags are not valid; even adding them to CGO_LDFLAGS_ALLOW
doesn't make a difference.
invalid flag in #cgo LDFLAGS: -Wl,
As a sidenote, I've decided it's better to just use static linkage on Windows anyway; maybe even on other platforms. I'll still help out figuring out this issue if needed.
Remove the space after the comma.
Right, thanks... It does link SDL2 dynamically but now it also requires libstdc++-6.dll
I'm importing this package alongside github.com/andlabs/ui and I get this error when cross-compiling to Windows using mingw:
The package ui uses C++, could this be confusing the Go linker into using C++ linkage for SDL2?