I’m trying to work out how we build Windows binaries. Is it just that we cross compile?
Reading through the build bot I see:
- export GOPATH=/var/lib/jenkins/workspace/BuildJuju-windows-amd64/_build
- export GOARCH=amd64
- export GOOS=windows
- go version
go version go1.11.5 linux/amd64
- go install github.com/juju/juju/cmd/juju github.com/juju/juju/cmd/jujud
That seems pretty clear that we are cross compiling.
The big issue is that it seems our new dependency on
github.com/coreos/go-systemd are causing real problems for me to just
go install github.com/juju/juju/....
The first problem was:
$ go install -v github.com/juju/juju/cmd/juju github.com/juju/juju/cmd/jujud github.com/juju/juju/vendor/github.com/coreos/pkg/dlopen # github.com/juju/juju/vendor/github.com/coreos/pkg/dlopen vendor\github.com\coreos\pkg\dlopen\dlopen.go:21:11: fatal error: dlfcn.h: No such file or directory // #include <dlfcn.h> ^~~~~~~~~ compilation terminated.
Searching around on the web seems there are other coreos complaints about missing this file, but also turns up:
Which has Make targets for mingw and visual studio 12 targets. (Though the Visual Studio Community edition seems to be 2017?)
Anyway, downloading that, and then copying dlfcn.h and libdlfcn.a to the mingw64 lib and include dirs gets past the first issue, then gives:
$ time go install -v github.com/juju/juju/cmd/juju/... github.com/juju/juju/vendor/github.com/coreos/pkg/dlopen # github.com/juju/juju/vendor/github.com/coreos/pkg/dlopen C:/Program Files/mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../lib/libdl.a(dlfcn.o):dlfcn.c:(.text+0x374): undefined reference to `EnumProcessModules' collect2.exe: error: ld returned 1 exit status
However, that seems to be just that you need to add “-lpsapi” for dlfcn-win32. Now, that requires editing a “vendor” directory, which I’m not fond of, but it makes progress.
But after doing all that, I then get:
$ time go install -v github.com/juju/juju/cmd/juju/... github.com/juju/juju/vendor/github.com/coreos/go-systemd/util # github.com/juju/juju/vendor/github.com/coreos/go-systemd/util util\util_cgo.go:122:11: could not determine kind of name for C.my_sd_pid_get_owner_uid util\util_cgo.go:121:10: could not determine kind of name for C.uid_t cgo: gcc errors for preamble: util\util_cgo.go:24:46: error: unknown type name 'uid_t'; did you mean 'pid_t'? // my_sd_pid_get_owner_uid(void *f, pid_t pid, uid_t *uid) ^~~~~ pid_t
I haven’t found a definitive reason why we’re missing ‘uid_t’. AFAICT it is supposed to be defined in
<sys/types.h> which is clearly being imported.
I feel like maybe the answer is that for jujud on windows we shouldn’t be including coreos. Because if we are, is it actually getting the right definitions that Windows needs for all of those header files, or is it compiling against the Linux definitions.