Fyne: Windows Build Support

[fkrick]

HIHo,

fist, thank for this awesome library !

is there any possibility or planings that we are able to build for Windows?

Currently i receive following error:

[fkrick@mucwsn2017-2 guiTest]$ env GOOS=windows GOARCH=amd64 go build src/guiTest/main.go
#github.com/fyne-io/fyne/desktop
src/github.com/fyne-io/fyne/desktop/app.go:12:31: undefined: NewEFLDriver
src/github.com/fyne-io/fyne/desktop/efl_windows.go:9:22: undefined: window

Best, Flo

[andydotxyz]

Hi,

You are very welcome :)
Absolutely it is intended to support cross-building - though there are some issues that we are going to have to solve.

I think the first issue you have hit is that you need CGO_ENABLED=1 as well because this is normally disabled when you set GOOS.

That should solve the immediate error but you may then see a different error...

[andydotxyz]

Now that we have moved to a no-native-dependency driver this should work much better.
As we still require CGo you may need to install the appropriate C compiler for your platform.

For example, to compile for windows from my Linux terminal I can use:

env CC=x86_64-w64-mingw32-gcc CGO_ENABLED=1 GOOS=windows go build main.go

[ghost]

Suggest to write a mage script to do compiles . This will make it way easier for users.

[andydotxyz]

An interesting suggestion. Unfortunately there is no standard way to install C compilers on Windows - so I’m not sure how we can automate it?

[AxelRHD]

I also have a problem compiling directly on Windows (7, 64bit) using Go 1.12 and MSYS2 C-compiler:

github.com/go-gl/glfw/v3.2/glfw

In file included from ....\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw\c_glfw_windows.go:6:0:
....\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/win32_monitor.c: In Funktion »createMonitor«:
....\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/win32_monitor.c:68:5: Warnung: Implizite Deklaration der Funktion »wcscpy«; meinten Sie »stpcpy«? [-Wimplicit-function-declaration]
wcscpy(monitor->win32.adapterName, adapter->DeviceName);
^~
stpcpy
....\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/win32_monitor.c: In Funktion »_glfwPlatformIsSameMonitor«:
....\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/win32_monitor.c:228:9: Warnung: Implizite Deklaration der Funktion »wcslen«; meinten Sie »scalbn«? [-Wimplicit-function-declaration]
if (wcslen(first->win32.displayName))
^~
scalbn
....\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/win32_monitor.c:229:16: Warnung: Implizite Deklaration der Funktion »wcscmp«; meinten Sie »wctomb«? [-Wimplicit-function-declaration]
return wcscmp(first->win32.displayName, second->win32.displayName) == 0;
^~
wctomb

command-line-arguments

D:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:\Users\DEU131~1\AppData\Local\Temp\go-link-636378579\000007.o: In function glfwSwapBuffers': D:\Dokumente\Development\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/context.c:609: undefined reference to__assert_func'
C:\Users\DEU131~1\AppData\Local\Temp\go-link-636378579\000007.o: In function glfwExtensionSupported': D:\Dokumente\Development\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/context.c:642: undefined reference to__assert_func'
C:\Users\DEU131~1\AppData\Local\Temp\go-link-636378579\000007.o: In function glfwGetProcAddress': D:\Dokumente\Development\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/context.c:707: undefined reference to__assert_func'
C:\Users\DEU131~1\AppData\Local\Temp\go-link-636378579\000007.o: In function glfwGetInputMode': D:\Dokumente\Development\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/input.c:153: undefined reference to__assert_func'
C:\Users\DEU131~1\AppData\Local\Temp\go-link-636378579\000007.o: In function glfwSetInputMode': D:\Dokumente\Development\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/input.c:174: undefined reference to__assert_func'
C:\Users\DEU131~1\AppData\Local\Temp\go-link-636378579\000007.o:D:\Dokumente\Development\golang\pkg\mod\github.com\go-gl\[email protected]\v3.2\glfw/glfw/src/input.c:262: more undefined references to `__assert_func' follow
collect2.exe: error: ld returned 1 exit status

[andydotxyz]

It looks like your issue could be the same as go-gl/glfw#202.
Can you confirm that the MSYS2 is the 64 bit variant and not the i686 (32) which could cause such a mismatch...
The result of go env may also help us to figure it out.

[AxelRHD]

go env is:
set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\DEU131138\AppData\Local\go-build set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=D:\Dokumente\Development\golang set GOPROXY= set GORACE= set GOROOT=D:\Go set GOTMPDIR= set GOTOOLDIR=D:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD= set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\DEU131~1\AppData\Local\Temp\go-build073054230=/tmp/go-build -gno-record-gcc-switches

and gcc -v:
Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-8.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build =x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-heade r-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x 86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --en able-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-strin g --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable -libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enab le-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disabl e-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mi ngw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sou rceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 8.3.0 (Rev1, Built by MSYS2 project)

[andydotxyz]

This is very curious. Can you confirm which directory you were building from and what command you used?
Also can you share the result of "which gcc" and "which go"?

[AxelRHD]

I just tested the "new" module workflow. Working directory is D:\Dokumente\Development\go-projects\gui_playground. "Which" or "whereis" ar no Windows commands. "Which gcc" inside of MSYS2 brings /mingw64/bin/gcc. The go.exe is in D:\Go\bin. I used the commands go build app.go and go run app.go.

[andydotxyz]

Ah, We don't support modules yet - I have not managed to get it to work and we will look into this more for the next release.
Can you try turning off modules and seeing if the problem goes away?

[AxelRHD]

Oh... didn't know that this can cause such errors. I will give it a try this afternoon.

[AxelRHD]

I moved the project to GOPATH src folder and removed the module files. Now it works fyne. ;)
Thank you for the great support.

[andydotxyz]

I'm glad to hear that it works, thanks.
We will need to support modules at some point but it's not a high priority right now.
If someone wanted to figure it out we would accept the pull request gladly :)