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