Linker: ld: library not found

[SWvheerden]

I am not sure if this is a bug or not, but after upgrading nightly versions,I keep getting this error:
ld: library 'ffi_lib' not found when trying to build a Rust Cucumber test containing a FFI library. Any help in either getting this resolved or fixed would be greatly appreciated.

So we have a cucumber test crate that tests an FFI crate.
The project structure looks as follows:

root
+---base
     +---ffi_lib
                +---cargo.toml
+---integration_tests
     +---cargo.toml 

We include the FFI library in the cargo.toml file with :

ffi_lib = { path = "../base/ffi_lib" }

Then its linked into the code via:

#[link(name = "ffi_lib")]
extern "C" {
    pub fn create_vector(tag: TTypeTag) -> *mut TVector;

The cargo.toml of ffi_lib contains this:

[lib]
crate-type = ["staticlib", "cdylib"]

Now this code works on Rust nightly-2024-08-03 and earlier, but as soon as you increase the version to nightly-2024-08-04 or later it breaks with:

error: linking with `cc` failed: exit status: 1
 note:  "cc" "/var/folders/47/s7....{}
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: ld: warning: ignoring duplicate libraries: '-liconv'
          ld: library 'ffi_lib' not found
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

I am struggling to find what rustc versions are used by these nightly version or docs about what could have changed. For what its worth this was done on a Mac M1, but fails on Unix CI as well with the same issue, so I doubt its a OSX only issue.

I can also see the ffi_lib library is built, and all its files are in the target folder.
Also
Running cargo +nightly-2025-05-01 test --all-features --release -v
I can see that rustc is adding in the -lffi_lib flag to include the library.

[Noratrieb]

Does it work on the latest nightly? You can try using cargo-bisect-rustc to narrow down what the problem could be.

But your setup seems a bit strange, you're adding it as a cargo dependency and then also linking it in via FFI? The problem can probably be resolved by adding the directory where you store the library to the linker library search path with a build script.

[SWvheerden]

yeah this is broken this nightly-2024-08-03 up to the latest.

We add it in via cargo as a dep to make sure its being build for the project, which dumps the lib into the release folder, where the linker can pick it up to link to it. As we don't use this a normal rust library in the test here, we specifically want to test it as an externally linked FFI.

[bjorn3]

We add it in via cargo as a dep to make sure its being build for the project

Adding a cdylib or staticlib as cargo dependency to a crate isn't guaranteed to work. You have to run cargo from for example a build script instead.

where the linker can pick it up to link to it.

Rustc is only guaranteed to look into the explicitly passed linker search paths which you can set using a build script: https://doc.rust-lang.org/stable/cargo/reference/build-scripts.html#rustc-link-search

[SWvheerden]

Yes, but by building it as part of the project, it builds it to the project dep folder cargo/<profile>/deps/*, it is automatically searched. And I can see the lib file in there. This whole process works.

My question is what changed between nightly-2024-08-03 and nightly-2024-08-04

Running cargo +nightly-2024-08-03 test --all-features --release, all the tests run, the FFI lib functions works etc,
Running cargo +nightly-2024-08-04 test --all-features --release, the build process fails with lib not found.

[Noratrieb]

Run cargo-bisect-rustc to narrow down the commit to see what changed

[bjorn3]

This was probably #128370 which stopped passing the crate search path to the linker as it is only supposed to be used for finding rust dependencies, not for arbitrary libraries exporting a C ABI (like cdylib and staticlib crates).

[SWvheerden]

cargo bisect-rustc --start=2024-08-03 --end=2024-08-04 -- test --no-run 
checking the start range to find a passing nightly
installing nightly-2024-08-03
testing...
RESULT: nightly-2024-08-03, ===> Successfully compiled
uninstalling nightly-2024-08-03

checking the end range to verify it does not pass
installing nightly-2024-08-04
rust-std-nightly-aarch64-apple-darwin: 25.31 MB / 25.31 MB [============================================================================================================================================================================================================================================================================================================================================] 100.00 % 8.43 MB/s testing...
RESULT: nightly-2024-08-04, ===> Compile error
uninstalling nightly-2024-08-04

searched toolchains nightly-2024-08-03 through nightly-2024-08-04
checking last toolchain to determine final result
installing nightly-2024-08-04
rust-std-nightly-aarch64-apple-darwin: 25.31 MB / 25.31 MB [==========================================================================================================================================================================================================================================================================================================================================] 100.00 % 831.55 KB/s testing...
uninstalling nightly-2024-08-04


********************************************************************************
Regression in nightly-2024-08-04
********************************************************************************

fetching https://static.rust-lang.org/dist/2024-08-03/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2024-08-03: 40 B / 40 B [=============================================================================================================================================================================================================================================================================================================================================================] 100.00 % 52.39 KB/s converted 2024-08-03 to fd8d6fbe505ecf913f5e2ca590c69a7da2789879
fetching https://static.rust-lang.org/dist/2024-08-04/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2024-08-04: 40 B / 40 B [============================================================================================================================================================================================================================================================================================================================================================] 100.00 % 466.18 KB/s converted 2024-08-04 to 64ebd39da5ec28caa3bd7cbb3f22f5949432fe2b
looking for regression commit between 2024-08-03 and 2024-08-04
fetching (via remote github) commits from max(fd8d6fbe505ecf913f5e2ca590c69a7da2789879, 2024-08-01) to 64ebd39da5ec28caa3bd7cbb3f22f5949432fe2b
ending github query because we found starting sha: fd8d6fbe505ecf913f5e2ca590c69a7da2789879
get_commits_between returning commits, len: 9
  commit[0] 2024-08-02: Auto merge of #128361 - Oneirical:testle-deforestation, r=jieyouxu
  commit[1] 2024-08-03: Auto merge of #128528 - workingjubilee:you-dont-need-to-see-this-cpuid-move-along, r=Amanieu
  commit[2] 2024-08-03: Auto merge of #128576 - weihanglo:update-cargo, r=weihanglo
  commit[3] 2024-08-03: Auto merge of #128356 - Oneirical:real-estate-reaLTOr, r=jieyouxu
  commit[4] 2024-08-03: Auto merge of #128595 - matthiaskrgr:rollup-7a4qa8b, r=matthiaskrgr
  commit[5] 2024-08-03: Auto merge of #128404 - compiler-errors:revert-dead-code-changes, r=pnkfelix
  commit[6] 2024-08-03: Auto merge of #128370 - petrochenkov:libsearch, r=bjorn3
  commit[7] 2024-08-03: Auto merge of #127324 - DianQK:match-br, r=cjgillot
  commit[8] 2024-08-03: Auto merge of #128614 - matthiaskrgr:rollup-d2fextz, r=matthiaskrgr
ERROR: no CI builds available between fd8d6fbe505ecf913f5e2ca590c69a7da2789879 and 64ebd39da5ec28caa3bd7cbb3f22f5949432fe2b within last 167 days

[SWvheerden]

I see #128370 in the list here

[bjorn3]

As I suspected. So basically it worked by accident before that PR and now you have to explicitly add the right directory to the linker search path.

[SWvheerden]

Awesome, let me get to fixing that, thanks for the help is figuring this out.
There are documents that do not explicitly state that the linker will now only search the local rust deps. But this can now be used a ref to show that