Provide option to enable dynamic linking of native libraries

[darix]

Since 1.4.7 it forces librocksdb to be linked statically. Many distros (including openSUSE) do not provide static libraries by default and avoid using them where possible.

[jevolk]

Thank you for reporting and I'm really sorry this happened. I believe @x86pup already has a fix staged for this. I'm currently away for a few more days but I'll be merging it later this week.

[x86pup]

Is there a specific error message that's being given? matrix-construct/rust-rocksdb#1 was a fix for liburing defaulting to static linking which is what I presume the real linker error is from that someone reported in the main room.

A more thorough option for only using dynamically linked libraries is doable since if I read the other default features correctly, bzip2 and libz are statically linked, but I don't believe librocksdb itself can be safely used in a dynamic context because tuwunel forks RocksDB for some minor changes including a new API (https://github.com/matrix-construct/rocksdb/commits/tuwunel-changes/). I would also anticipate a lot of potential problems that arise from distributions only packaging older/ancient versions of RocksDB, also with regards to only newer APIs that exist that tuwunel makes extensive use for that give it its huge performance edge.

[darix]

https://build.opensuse.org/package/live_build_log/home:darix:apps/tuwunel/openSUSE_Tumbleweed/x86_64

also if you need newer versions of rocksdb. pkgconfig has a flag to specify the minimum version you need. this is all a solved problem.

[x86pup]

The build log looks like matrix-construct/rust-rocksdb#1 will solve the liburing error at least. Maybe after that gets merged, see how much it progresses after that.

[darix]

I updated my package to 1.4.7+git6.b5f50c3f. it builds again but I do not see that it links the system copies of the libraries even though the shared libraries are available during the build.

[jevolk]

what is the output for ldd of the tuwunel binary?

[darix]

ldd tuwunel
        linux-vdso.so.1 (0x00007f9eced73000)
        liburing.so.2 => /lib64/liburing.so.2 (0x00007f9eced44000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f9ec9e00000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9eced17000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f9eca105000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f9ec9a00000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9eced75000)

[jevolk]

If you are expecting a link to /lib64/librocksdb.so it's not likely to happen. June explained it in the earlier comment

The versioning and ABI differences alone make this a significant challenge, I've actually done this before and even that is just a build-time compatibility scheme, a dlopen() to a shlib goes even further with a runtime adjustment of the FFI based on the version it finds. On most distros that version is frustratingly old. It would be nice to have in rust-rocksdb but the reward is hardly worth the cost. Static rocksdb doesn't add much weight to the binary in a proper build, and offers equal or better performance than the shlib from optimization opportunities.