When compiling leveldb-sys on an RPM-based distro (Amazon Linux), I encountered a linking issue where rustc couldn't find the static libraries. Running with cargo build -v revealed that rustc was looking in target/debug/build/leveldb-sys-c386c93bc8ab6af5/out/lib, while the actual libraries had been placed in target/debug/build/leveldb-sys-c386c93bc8ab6af5/out/lib64 (i.e. lib64 instead of lib).
In an attempt to fix the issue in a portable way, I've modified build.rs so that it defines CMAKE_INSTALL_LIBDIR when invoking CMake, causing it to always output the lib archives in a predictable location (i.e. always lib). I've tested this change on Amazon Linux, Ubuntu 20.04 and macOS 10.15 and it works on all of them.
PS: I noticed that the commit for v2.0.6 isn't on master; this PR targets master but I'm happy to rebase as necessary
When compiling
leveldb-sys
on an RPM-based distro (Amazon Linux), I encountered a linking issue whererustc
couldn't find the static libraries. Running withcargo build -v
revealed thatrustc
was looking intarget/debug/build/leveldb-sys-c386c93bc8ab6af5/out/lib
, while the actual libraries had been placed intarget/debug/build/leveldb-sys-c386c93bc8ab6af5/out/lib64
(i.e.lib64
instead oflib
).In an attempt to fix the issue in a portable way, I've modified
build.rs
so that it definesCMAKE_INSTALL_LIBDIR
when invoking CMake, causing it to always output the lib archives in a predictable location (i.e. alwayslib
). I've tested this change on Amazon Linux, Ubuntu 20.04 and macOS 10.15 and it works on all of them.PS: I noticed that the commit for v2.0.6 isn't on
master
; this PR targetsmaster
but I'm happy to rebase as necessary