Support all features on all targets when releasing

[binarylogic]

Currently, Vector releases "limited" versions on select targets, such as x86_64-unknown-linux-musl. This is due to the fact that we have been unable to compile and statically links the leveldb and rdkafka libraries. Vector uses leveldb for on-disk buffering and rdkafka for the kafka sink.

As a short term solution we've hidden these features behind cargo feature flags, enabling the ability to build Vector without these features, which in return allow Vector to compile successfully:

cargo build --no-default-features

This, obviously, is not ideal and is something we should resolve. A few ideas:

1. Work on compiling and linking these libraries in the problematic targets.
2. Move off of these libraries and replace them with Rust native libraries that do not require external dependencies.

[ghost]

Both leveldb and rdkafka should in theory work with musl, as they are successfully packaged for Alpine:

• https://pkgs.alpinelinux.org/package/edge/community/x86_64/leveldb
• https://pkgs.alpinelinux.org/package/edge/community/x86_64/librdkafka

If the primary goal of compiling Vector for x86_64-unknown-linux-musl is to release an Alpine package (as in #630), it might be easier to just link with these libraries dynamically and add them to the package dependencies.

[ghost]

I've built Vector on Alpine. The result is in this repository.

Both leveldb and rdkafka were compiled fine, even statically, so I suppose the problem might be not with musl itself, but rather with the base image japaric/x86_64-unknown-linux-musl or some of the installed packages.

The output of ldd looks like this,

/lib/ld-musl-x86_64.so.1 (0x7f693b5c0000)
libz.so.1 => /lib/libz.so.1 (0x7f693a056000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f6939f01000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f6939eed000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f693b5c0000)

so both leveldb and rdkafka are actually statically linked.

[LucioFranco]

Oh wow really nice!!!! This seems like it could work! I think the big key here is actually the fact that you brought in snappy as a dynamic lib here? Do you think it will still work if we strip all those apk dependencies after compile?

[ghost]

No, snappy is linked statically, as it is not listed in ldd output.

Here zlib is linked dynamically, but the binary from vector-0.3.0-x86_64-unknown-linux-gnu.tar.gz is linked to to zlib dynamically too:

$ ldd vector
        linux-vdso.so.1 (0x00007ffe58f6e000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f79502da000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f79500bc000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f794ff38000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f794ff33000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f794ff29000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f794ff0f000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f794fd4c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f79519b3000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f794fbc9000)

[ghost]

zlib can be linked statically too, as libz-sys crate supports static linking.

With this flag ldd output looks like

/lib/ld-musl-x86_64.so.1 (0x7f7bf6f96000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f7bf58e3000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f7bf58cf000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f7bf6f96000)

[LucioFranco]

This is really great! I def would like to remove the dynamic linking into libz. I think this is super useful and will greatly improve our builds. Thanks!

[binarylogic]

Closing, this was solved by #689 for musl. Issues like #859 and #732 cover individual platforms.