Repository: rust
Issue: FFI -L linker paths ignored on Linux but work on Mac
Labels: A-linkage,O-linux

I manage the [Rutie](https://github.com/danielpclark/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.