Windows build 64 bit challenges

[rashwell]

First in this environment:

>systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.14393 N/A Build 14393

>go version
go version go1.7.1 windows/amd64

>go env
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=c:\gowork
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\MYNAME\AppData\Local\Temp\go-build786307330=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1

with this qt:

https://download.qt.io/official_releases/qt/5.7/5.7.0/qt-opensource-windows-x86-android-5.7.0.exe

I think the issue might be that this isn't a 64bit compiler in the above.

I don't know why it works but qtdeploy works just fine and I can build apps, etc.

But if I ever try and:

go build
# github.com/therecipe/qt/core
cc1.exe: sorry, unimplemented: 64-bit mode not compiled in

In a way I think this also causes issues with gocode which makes it hard to have intellisense in stuff like atom/vscode, etc actually work because gocode I think just does go builds to resolve external contexts and when debugging gocode output or lack there of I see things like this everytime a request is made:

2016/10/30 12:59:41 Import path "github.com/therecipe/qt/widgets" was not resolved
2016/10/30 12:59:41 Gocode's build context is:
2016/10/30 12:59:41  GOROOT: C:\Go\
2016/10/30 12:59:41  GOPATH: c:\gowork
2016/10/30 12:59:41  GOOS: windows
2016/10/30 12:59:41  GOARCH: amd64
2016/10/30 12:59:41  BzlProjectRoot: ""
2016/10/30 12:59:41  GBProjectRoot: ""
2016/10/30 12:59:41  lib-path: ""
2016/10/30 12:59:42 Autobuild error: exit status 2

Even though all of it is up to date, and qtsetup etc ran without issues, and built it all.

[5k3105]

Hi,

I use LiteIDE and gocode does not like to parse this qt binding.

I've tried IntelliJ and it parses everything EXCEPT widgets.. I've even attempted Vim and well, I can't get that to work at all - probably my own fault though.

So yes - I think gocode just can't cope with qt/widgets because it's so large.

Maybe we should take this up with gocode.

[therecipe]

Yes, there are problems with gocode auto-completion and with plugins that rely on it.
(Even through I'm not thinking that everything fallbacks to gocode)

For example it works with Atom + autocomplete-go on macOS.
And fcying fixed his neovim plugin here: #51 (comment)

From the output above it seems like the plugin uses GOARCH: amd64, but the binding is installed and later compiled with GOARCH: 386 on Windows (because Qt only provides prebuild x86 libs)

Therefore the plain go build/run command doesn't work with go1.7.1 windows/amd64.
And you need to set GOARCH to 386 before invoking go run/build.

Could you change the env of the plugin to GOARCH: 386 and report back?

Or use the stub version with QT_STUB which doesn't use cgo and therefore works with 386 and amd64. (But you won't be able to use go build/run)

(Or use the go1.7.1 windows/386 version)

It may be necessary to update the README to make people aware of this.

[renannprado]

@5k3105 I only got it working on IntelliJ after I increased the JVM memory.

[5k3105]

Hi,

For IntelliJ:

Help > Edit Custom Properties

# custom IntelliJ IDEA properties

idea.max.intellisense.filesize=999999

Help > Edit Custom VM Options

# custom IntelliJ IDEA VM options

-Xms128m
-Xmx2000m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops

[omac777]

I only tried the original qt.io -based 32-bit binaries and yes they work, but when using 32-bit msys2
shell and packages as the original therecipe recommended.

Were you aware of these windows msys2 64-bit binaries available?
With msys2 64-bit binaries as mentioned:
https://wiki.qt.io/MSYS2#Obtain_Pre-Built_Qt_.26_QtCreator_binary_files_and_Use_instantly_without_Building.2FCompiling

pacman -S mingw-w64-i686-qt-creator mingw-w64-x86_64-qt-creator
pacman -S mingw-w64-i686-qt5-static mingw-w64-x86_64-qt5-static

Will your bindings work with that within the windows 64-bit msys2 shell?

I undersatnd QT_DIR won't work because pacman installs it into the standard linux directories unlike the qtdistro does. But you did mention:
export QT_PKG_CONFIG=true
Has it been confirmed to work with the above yet?

[larrylau]

another question:
how to link qt using static library?

[therecipe]

@omac777
Thanks, didn't know about those.
I will try to get it working with them as well.

Unfortunalley QT_PKG_CONFIG has only an effect on Linux systems currently.

@larrylau
Here is an example how @gen2brain static linked it on Linux and even static cross compiled it to Windows #55
But you would needed to either build the static Qt version on your own or obtain the static compiled commercial version.
Also you will need to use qtmoc, qtminimal, qtrcc and go build -tags=minimal ... and also figure out the missing CGO_* flags.

qtdeploy might do this for you in the future, but currently you have to do it manually.

[therecipe]

@omac777

Added support for MSYS2 with d0152ba

[larrylau]

I tested mingw64 on MSYS2, I have two problems.
my GOROOT is d:\go\go and GOPATH is d:\go\golang

1. In the MSYS2, I must export GOROOT=d:/go/go to run qtsetup, export GOROOT=/d/go/go I got failed.
2. The QT's version in MSYS2 is 5.6.2, under QT_STUB mode ,some include files will not be found.

[therecipe]

@larrylau

Did you needed to explicitly export the GOROOT?

In the MSYS2, I must export GOROOT=d:/go/go to run qtsetup, export GOROOT=/d/go/go I got failed.

export GOROOT=/d/go/go probably won't work because Go doesn't care that it's run inside the mingw64 shell and still wants to use the normal Windows paths. (C:/, D:/, ...)

The QT's version in MSYS2 is 5.6.2, under QT_STUB mode ,some include files will not be found.

Yes, the support for MSYS2 on Window, Homebrew on macOS and Pkg-Config on Linux is still somewhat experimental, but it should never less work.

The problem is, that I didn't made it fully backwards compatible to previous versions of Qt yet.
So the missing include file messages are expected and the qtsetup should continue.

Did the examples show up for you?
And are you able to test the examples with qtdeploy?

[larrylau]

Go doesn't care that it's run inside the mingw64

OK, I see.

Did the examples show up for you?

they are showed.

And are you able to test the examples with qtdeploy?

I just run qtsetup， some error was occurred.
msg="failed to test qml\application\nerror:

......

goroutine 1 [running]:
panic(0x5d17e0, 0xc0477d49b0)
D:/go/go/src/runtime/panic.go:500 +0x1af
github.com/Sirupsen/logrus.Entry.log(0xc04200e2d0, 0xc04b96d4d0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc044db9500, ...)
D:/go/golang/src/github.com/Sirupsen/logrus/entry.go:124 +0x42a
github.com/Sirupsen/logrus.(_Entry).Panic(0xc0477d4960, 0xc044db9558, 0x1, 0x1)
D:/go/golang/src/github.com/Sirupsen/logrus/entry.go:169 +0x12b
github.com/Sirupsen/logrus.(_Entry).Panicf(0xc0477d4960, 0x5e2be2, 0x1e, 0xc044db9600, 0x3, 0x3)
D:/go/golang/src/github.com/Sirupsen/logrus/entry.go:217 +0x108
github.com/therecipe/qt/internal/utils.RunCmd(0xc0422bec60, 0xc047d01360, 0x14, 0x1, 0x1)
D:/go/golang/src/github.com/therecipe/qt/internal/utils/utils.go:71 +0x222
main.test(0x5dac09, 0x7)
D:/go/golang/src/github.com/therecipe/qt/cmd/qtsetup/test.go:44 +0x10e5
main.main()
D:/go/golang/src/github.com/therecipe/qt/cmd/qtsetup/setup.go:82 +0x3ec

[therecipe]

Okay, could you try to build the qml/application manually with
qtdeploy build desktop path/to/qml/application >> output.txt 2>&1
(it will dump the error log inside output.txt and don't show any output)

And show me a part of the output?
I probably only need the part where it says something like msg="failed to build for ...

And also, are you able to build the other examples like widgets/lineedits manually with qtdeploy?

[jordanorelli]

cc1.exe: sorry, unimplemented: 64-bit mode not compiled in

this error means that you're using a 32-bit version of gcc. The Qt community edition installer installs a 32-bit version of gcc, which, if you follow the readme directions, winds up on %path%. Oddly, qtdeploy.exe works fine and somehow locates the correct, 64-bit gcc in this situation, but it breaks cgo, which winds up looking at the incorrect, 32-bit gcc. This problem plagued me for ... about a day and a half, haha.

I'm not sure how qtdeploy.exe selects the version of gcc to use, but at least in my install, it wound up that cgo and qtdeploy were looking at different versions of gcc. tbh I just walked away from that and did everything through MSYS2, and now I have qtdeploy and cgo both working independently of one another, but I'm still trying to wrap my head around the whole MSYS2 + MinGW-64 + cgo + Qt build chain.

[therecipe]

@jordanorelli

I'm not sure how qtdeploy.exe selects the version of gcc to use

On windows (for the desktop target) qtdeploy always uses the gcc version that is found inside the PATH.

The Qt community edition and MSYS2 mingw32 both provide a 32-bit gcc versions, so go build also compiles with GOARCH=386.
Only the MSYS2 mingw64 shell provides a 64-bit gcc version, so go build compiles with GOARCH=amd64

You could also just use qtmoc, qtrcc, qtminimal and go build (-tags=minimal) instead of qtdeploy to get more control about your builds.