Open danielpclark opened 5 years ago
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
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.
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 eithertarget/debug/deps
ortarget/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
tocargo: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 viacargo:rustc-link-search=native=/some/path
orcargo:rustc-link-search=/some/path
orcargo:rustc-link-search=dependency=/some/path
with either ruby lib nameruby
orruby-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*
intarget/$PROFILE/deps
Mac
No symlink or copy
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-L182This 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.