attempt to support windows #9
Conversation
tamird
commented
Oct 28, 2015
tamird
commented
|
How have you tested this? If we're going to attempt to support windows, appveyor.com is a good windows-based CI platform (and you can set up multiple CI systems with github; I do this for Tornado). However, this seems like an unnecessary distraction as we're approaching beta and we should wait to explore this until post-beta. |
|
Yes, I agree. I was trying to get cross-compilation working using https://github.com/karalabe/xgo, and wanted to document what I had tried. I won't be actively working on this. |
|
I should mention that this currently fails in xgo: karalabe/xgo#26 |
| // #cgo CPPFLAGS: -DNDEBUG -DSNAPPY -DLZ4 | ||
| // #cgo darwin CPPFLAGS: -DOS_MACOSX -DROCKSDB_PLATFORM_POSIX | ||
| // #cgo linux CPPFLAGS: -DOS_LINUX -DROCKSDB_PLATFORM_POSIX | ||
| // #cgo windows CPPFLAGS: -DOS_WIN |
There was a problem hiding this comment.
Is someone asking for windows support? Just curious what motivated this.
There was a problem hiding this comment.
Nah, I was trying to get cross-compilation working so we could post binaries and wanted to see how far I could get with windows.
|
LGTM |
- Downcase some `#include`s since we run on case-sensitive file systems - Avoid MSVC's `i64` suffix which isn't supported in GCC
TL;DR: Portable Executables (Windows) don't support missing symbols after link-time, and the go toolchain doesn't link dependencies into cgo archives. See golang/go#14985.
|
Hey, this is ready for another look. For now, I've worked around some issues by omitting snappy on windows. This compiles successfully with |
|
|
