Cargo test is not loading dynamic library (macos)

[josephg]

Problem

The rust foundationdb bindings depend on libfdb_c.dylib in /usr/local/lib. cargo test fails because it can't find the library, but when I invoke the compiled library directly it works.

This is a regression - it works fine in stable. It only fails in cargo from nightly.

$ cargo test
    Finished dev [unoptimized + debuginfo] target(s) in 1.06s
     Running target/debug/deps/foundationdb-997674909324b5af
dyld: Library not loaded: libfdb_c.dylib
  Referenced from: /Users/josephg/src/ff2-rs/target/debug/deps/foundationdb-997674909324b5af
  Reason: image not found
error: process didn't exit successfully: `/Users/josephg/src/ff2-rs/target/debug/deps/foundationdb-997674909324b5af` (signal: 6, SIGABRT: process abort signal)

But if I invoke the executable directly:

$ /Users/josephg/src/ff2-rs/target/debug/deps/foundationdb-997674909324b5af
running 19 tests
test fdb_api::tests::test_max_api ... ok
test subspace::tests::pack_unpack ... ok
...

test result: ok. 19 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Tested on:

• cargo 1.33.0-nightly (907c0fe 2019-01-20) / nightly toolchain 2019-01-20 (fails)
• cargo 1.34.0-nightly (2458180 2019-01-27) / nightly toolchain 2019-02-02 (fails)
• cargo 1.32.0 (8610973 2019-01-02) (works)

I haven't tested this on linux or windows.

Probably related to #3366

Steps

1. Either install foundationdb from here, or just download libfdb_c.dylib and place it in /usr/local/lib
2. git clone https://github.com/bluejekyll/foundationdb-rs.git. I've been reproducing this problem using the current master (Clikengo/foundationdb-rs@95d49a1)
3. cargo test. The test binary should launch, then run or complain about not being able to connect to your cluster.

Notes

I tried adding cargo:rustc-link-search=/usr/local/lib in foundationdb-sys's build.rs file, but that seems to have no effect.

I'm not sure how to inspect cargo's testing environment (environment variables / command line options / etc).

fdb issue: Clikengo/foundationdb-rs#112

[josephg]

I've binary searched nightly versions - the regression was added between commit 0d1f1bb (works) and 34320d2 (fails). Looks like the problem is #6355, which sets DYLD_FALLBACK_LIBRARY_PATH.

@ehuss from that thread:

I'm concerned that this overrides the default $(HOME)/lib:/usr/local/lib:/lib:/usr/lib. Anything expecting libraries in those locations that aren't encoded in @rpath will start to fail. I don't know how likely that is, though. I don't know under which circumstances libraries aren't found via @rpath (or why setting DYLD_*_PATH is ever necessary). To be on the safe side, maybe it should include the defaults?

Sure enough:

$ DYLD_FALLBACK_LIBRARY_PATH=. /Users/josephg/src/ff2-rs/target/debug/deps/foundationdb-39bc6296859aef1d
dyld: Library not loaded: libfdb_c.dylib
  Referenced from: /Users/josephg/src/ff2-rs/target/debug/deps/foundationdb-39bc6296859aef1d
  Reason: image not found
Abort trap: 6

$ DYLD_FALLBACK_LIBRARY_PATH=/usr/local/lib /Users/josephg/src/ff2-rs/target/debug/deps/foundationdb-39bc6296859aef1d

running 19 tests
test fdb_api::tests::test_max_api ... ok
test subspace::tests::pack_unpack ... ok
...

[ehuss]

Sorry about that, a recent change altered DYLD_FALLBACK_LIBRARY_PATH, and I suspected it might break, but I never followed up. I'll try to fix this soon.

As a temporary workaround, you can run DYLD_FALLBACK_LIBRARY_PATH=/usr/local/lib cargo test