Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
FFI -L linker paths ignored on Linux but work on Mac #57550
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
Without copying or symlinking the libruby file to my local deps directory I would have to switch away from
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
So here's the working setup for:
No symlink or copy
And yes I know
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
This has all been tested with the latest Rust