FFI -L linker paths ignored on Linux but work on Mac

[danielpclark]

I manage the Rutie project which wraps libruby allowing Ruby & Rust to be used together. It has taken a long time to discover what the weird behavior was here so let me explain what's going on.

First the environment I test against is a system that has Ruby installed within the main operating system. But that is not the Ruby I'm providing to cargo/rustc as a linker path to use as I'm using RVM (Ruby Version Manager) to dynamically change the shell environment of which Ruby I'm using and they are stored in a sub directory in my users home directory. The compiled code doesn't change which Ruby it uses when the shell does, the code only uses whichever Ruby is current during the build process.

On Linux (Ubuntu & TravisCI/Linux) for the longest time I would find the linker wouldn't work unless I copied the actual libruby.so (eg: libruby.so.2.6) file into either target/debug/deps or target/release/deps. Then everything passes the continuous integration server tests.

Without copying or symlinking the libruby file to my local deps directory I would have to switch away from cargo:rustc-link-lib=ruby to cargo:rustc-link-lib=ruby-2.5 and then only one of the three Ruby versions would pass the tests and that's because Rust found the system installed Ruby but ignored all provided paths via cargo:rustc-link-search=native=/some/path or cargo:rustc-link-search=/some/path or cargo:rustc-link-search=dependency=/some/path with either ruby lib name ruby or ruby-2.5.

Now putting having the right name of the lib which works aside, which is different for Mac, the Mac OS would accept the paths provided as shown above and correctly use the correct Ruby, of which RVM had installed, over the systems installed Ruby.

So since I've discovered that Rust/cargo wasn't acknowledging paths provided by the linker in which the Ruby library resides I have made it so my build.rs script always symlinks the correct lib into the current target profile dependency directory.

So here's the working setup for:

Linux

Symlink: libruby.so.2.6 -> $HOME/.rvm/rubies/ruby-2.6.0/lib/libruby.so.2.6* in target/$PROFILE/deps

cargo:rustc-link-search=/home/travis/.rvm/rubies/ruby-2.6.0/lib
cargo:rustc-link-lib=ruby
cargo:rustc-link-lib=dylib=ruby
cargo:rustc-link-lib=m

Mac

No symlink or copy

cargo:rustc-link-search=/Users/travis/.rvm/rubies/ruby-2.6.0/lib
cargo:rustc-link-lib=ruby.2.6
cargo:rustc-link-lib=dylib=ruby.2.6

---

And yes I know ruby is listed twice and that it's not necessary.

The main point of this issue is a known working build for Mac OS does not behave the same way in Linux as the libraries in the provided linked paths are not honored.

If you would like to replicate the failure simply comment out the symlink code in the build.rs file here: https://github.com/danielpclark/rutie/blob/v0.5.3/build.rs#L174-L182

This has all been tested with the latest Rust rustc 1.31.1 (b6c32da9b 2018-12-18) and I've been struggling with this same issue over the past couple of years both on my computer and in the CI environment. As I said I only recently understood where the issue comes from.

[madsmtm]

Sorry for the necropost, am cleaning up old macOS issues. It doesn't sound like this is an issue with macOS though, so I'll: @rustbot label -O-macos

[bjorn3]

I think the issue is that you only have libruby.so.2.6 and are missing a symlink from libruby.so to libruby.so.2.6. The linker will only search for libruby.so if you pass it -lruby. It will never search for libruby.so.2.6 or anything else with a version after .so. One of the main things -dev packages on linux contains are those symlinks from libfoo.so to libfoo.so.1.2.3 for linkers to find the right library to link to.