Support Windows as a release target

[binarylogic]

This is a follow up to #879. We've received this request a few times and I'd like to start by reviewing exactly how difficult this would be and then determining if we'd like to proceed or not.

[ghost]

I’m not sure how satisfactory it would be, but it looks like MUSL binary for Linux should just work on WSL. I don’t have a Windows machine at hand now to test it though. If it works and if supporting only Windows systems with WSL is fine, we can additionally make a Chocolatier package to install a wrapper to make it possible to invoke just vector instead of wsl ./vector.

Alternatively, we can try to compile natively. It probably would be easiest to do with MinGW (native dependencies build scripts should work similarly to Linux), although it would link to some LGPL libraries. I’m not sure would MSVC community license allow us to use it for Vector, but if it would, it it is also a question do all native dependencies support building with MSVC tools instead of make and POSIX-compatible C compiler command line interface. An interesting venue to explore is creation of a new target triple based on Clang, which is something not reported to be done yet.

[mchesser]

I had a go at compiling on Windows using MSVC, and it mostly works though I had to disable several features (namely file sources/sinks, signal handling, and leveldb persistence).

The metrics library (hotmic) is also problematic (causes an infinite loop on windows) because it uses an outdated version of crossbeam-channel that suffers from an issue in the atomic cell implementation (see: crossbeam-rs/crossbeam#388).

My fork here: (https://github.com/mchesser/vector) should compile and appears to work (though I didn't really perform any amount of testing) when compiling with --default-features=false.

[ghost]

I experimented with compilation of Vector on Windows under MSYS2/MINGW64. There were a few problems:

• file source uses Unix-specific features (see file source uses Unix-specific methods from the standard library #1101 for details)
• file sink uses OsStrExt - probably, can be worked around.
• syslog uses Unix-specific features too, but I'm not sure should it be supported on Window at all or not.
• Signal handling in main.rs is Unix-specific, I think it should be put behind #[cfg(unix)].

Note that I was compiling Vector 0.4.0 because it is the latest version supporting Rust 1.37 and this is the version of Rust in MSYS2 repository. The version 1.38 from rustup links to older version of MINGW libraries and is not compatible with the latest MSYS2. One way to overcome this problem is to recompile Rust, but there also might be a better option.

Status of the dependencies behind feature flags:

• The version of leveldb crate from our fork was compiled successfully.
• librdkafka is reported to have Windows support, but only for MSVC. With some tweaking of its C code I was able to compile it with MINGW, but not link (there were a lot of errors about duplicated symbols and also missing symbols).
• There were issues with compiling jemalloc, but I didn't investigate them as in my opinion jemalloc feature is more optional than others.