Open elvarb opened 9 years ago
Unfortunately, I'm currently seeing unacceptably poor throughput when I test locally with Go 1.5 on Linux. Also, we've seen Heka crash under load testing due to stack frame boundary panics, again with Go 1.5 on Linux. So we're not yet ready to commit to using Go 1.5 for all of our builds.
Still, I'll do some testing on Windows before the next release. Even if we're still using Go 1.4 for the other builds I'll likely end up putting out Windows binaries built w/ Go 1.5, albeit with a "use at your own risk" warning.
:+1:
Any update on this now that we have the 0.10.0 release?
We're still building Heka w/ Go 1.4, because with 1.5 we see worse throughput as well as intermittent segfaults. Unfortunately, the Go change that alleges to fix the cgo issue that burns us landed after 1.4, so we can't yet offer a Windows build that we can stand behind.
We have longer term plans to move a lot of the sandbox interaction functionality that's currently happening in Heka's Go code into C as a part of the sandbox project itself, which would both improve performance and greatly reduce the required surface area of the cgo interactions. Much less cgo means we will likely be routing around the underlying issue altogether. When this is done we'll likely upgrade to a more recent Go, and we should be able to again start releasing Windows binaries.
@rafrombrc: What is the cgo issue in question?
I would love a Windows binary.
I am unable to build, since
1) Git requires sh.exe
, otherwise I get:
fatal: 'submodule' appears to be a git command, but we were not
able to execute it. Maybe git-submodule is broken?
CMake Error at C:/gopath/src/github.com/mozilla-services/heka/build/ep_base/tmp/go-notify/go-notify-gitclone.cmake:37 (message):
Failed to init submodules in:
'C:/gopath/src/github.com/mozilla-services/heka/build/heka/src/github.com/rafrombrc/go-notify'
CMakeFiles\go-notify.dir\build.make:87: recipe for target 'ep_base/Stamp/go-notify/go-notify-download' failed
mingw32-make[2]: *** [ep_base/Stamp/go-notify/go-notify-download] Error 1
CMakeFiles\Makefile2:1197: recipe for target 'CMakeFiles/go-notify.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/go-notify.dir/all] Error 2
Makefile:159: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
2) If I have sh.exe
in my path I get:
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.4/Modules/CMakeMinGWFindMake.cmake:22 (message):
sh.exe was found in your PATH, here:
C:/git/usr/bin/sh.exe
For MinGW make to work correctly sh.exe must NOT be in your path.
Run cmake from a shell that does not have sh.exe in your PATH.
If you want to use a UNIX shell, then use MSYS Makefiles.
Call Stack (most recent call first):
CMakeLists.txt:5 (project)
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
CMakeFiles\lua_hyperloglog.dir\build.make:104: recipe for target 'ep_base/Stamp/lua_hyperloglog/lua_hyperloglog-configure' failed
mingw32-make[5]: *** [ep_base/Stamp/lua_hyperloglog/lua_hyperloglog-configure] Error 1
CMakeFiles\Makefile2:1147: recipe for target 'CMakeFiles/lua_hyperloglog.dir/all' failed
mingw32-make[4]: *** [CMakeFiles/lua_hyperloglog.dir/all] Error 2
Makefile:159: recipe for target 'all' failed
mingw32-make[3]: *** [all] Error 2
CMakeFiles\lua_sandbox.dir\build.make:111: recipe for target 'ep_base/Stamp/lua_sandbox/lua_sandbox-build' failed
mingw32-make[2]: *** [ep_base/Stamp/lua_sandbox/lua_sandbox-build] Error 2
CMakeFiles\Makefile2:1605: recipe for target 'CMakeFiles/lua_sandbox.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/lua_sandbox.dir/all] Error 2
Makefile:159: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
I cannot resolve this catch 22. Prior to this, I could rename sh.exe
, and it would get through the build script eventually. This doesn't work anymore.
Does anybody have an unofficial win64 binary? ;)
It's been several months - are there any pending issues preventing windows builds on Go 1.6?
@klauspost wrote:
I cannot resolve this catch 22. Prior to this, I could rename sh.exe, and it would get through the build script eventually. This doesn't work anymore.
This problem still exists currently. I was able to work around it by:
C:\git\usr\bin
from the Windows PATH
environment variablesC:\tools
and placing patch.exe
there.C:\tools
to the windows PATH
It is not ideal, but it at least allowed me to build something. YMMV
Does anybody have an unofficial win64 binary? ;)
For those interested, this is what I ended up with: USE AT YOUR OWN RISK heka_dev-windows-amd64.zip - Built against 9c6ae0a447cdcf192c1ad220248ca989490531fe with go1.6
The Issue referenced as a blocker for Windows binaries has now been closed in version 1.5 of go
https://github.com/golang/go/issues/9754
Will we see a Windows binary soon?