dylib dependency of proc-macro causes build to fail with opaque error message

[gmorenz]

Problem

If you have a proc-macro depend on a crate with crate-type=["dylib"] building the proc-macro apparently succeeds, but then building the crate which uses it fails with an error message

error[E0463]: can't find crate for `macone`
 --> user/src/main.rs:1:1
  |
1 | macone::macone!();
  | ^^^^^^ can't find crate

This occurs because LD_LIBRARY_PATH is not set when running rustc to build the final crate that uses the proc macro, and as a result it can't find the shared dep. And rustc's error messages here aren't very good.

Steps

git clone https://github.com/gmorenz/shared_proc_macro_dep/
cd shared_proc_macro_dep/user
cargo build

Possible Solution(s)

There are three solutions here:

1. Error if proc macros depend on dylib's (or probably cdylibs)
2. Provide LD_LIBRARY_PATH to rustc invocations.
3. Kick this out to rustc to provide better error messages when building the crate that depends on a proc macro that it fails to load. Which it probably should - but its not in the same position as cargo is to understand why that's failing.

The second option would enable things like this (without hacks): facet-rs/facet#1143

The first is probably less work.

Notes

No response

Version

cargo 1.93.0-nightly (2a7c49606 2025-11-25)
release: 1.93.0-nightly
commit-hash: 2a7c4960677971f88458b0f8b461a866836dff59
commit-date: 2025-11-25
host: x86_64-unknown-linux-gnu
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.15.0-DEV (sys:0.4.83+curl-8.15.0 vendored ssl:OpenSSL/3.5.4)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Arch Linux Rolling Release [64-bit]

[bjorn3]

The dlopen error message is supposed to be propagated. There is a dedicated CrateError variant for it: https://github.com/rust-lang/rust/blob/ba86c0460b0233319e01fd789a42a7276eade805/compiler/rustc_metadata/src/locator.rs#L1107-L1109 I'm not sure where that error got swallowed.

[bjorn3]

In any case this error message is caused by rustc, so

@rustbot transfer rust

[bjorn3]

Didn't notice you opened rust-lang/rust#149725 as separate issue on the rust side already.

[bjorn3]

Let me transfer it back I guess.

@rustbot transfer cargo

[gmorenz]

Yeah... I really think there's both a cargo and a rust bug here.

Cargo knows that this is going to fail when it sees the crate graph, and why, and should tell the user that before building the crates (or at least when building the proc-macro that it can't use). Or alternatively it should fix things so they don't fail.

Rust can't do any of that, it should surface the dlopen error, but that's all it can do.

[ehuss]

This is supposed to work, and looks like it regressed in nightly-2024-10-06. I think it is almost certainly rust-lang/rust#131188.

LD_LIBRARY_PATH is not set when running rustc

I don't think this is correct. You can run with -vv to see the environment variables cargo sets, and it does set LD_LIBRARY_PATH. The problem is that libstd.so is no longer included in the sysroot.

I'm not sure what cargo can do here. It's not clear if this is something the compiler team intends to support.

[gmorenz]

Oh, interesting, I was just wrong about LD_LIBRARY_PATH then. For what it's worth I misdiagnosed it after realizing the following worked

rustc -C prefer-dynamic --crate-type dylib --edition 2024 --crate-name shared_dep shared_dep/src/lib.rs
rustc -C prefer-dynamic --crate-type proc-macro --edition 2024 --extern shared_dep=libshared_dep.so --crate-name macone macone/src/lib.rs
rustc -C prefer-dynamic --crate-type proc-macro --edition 2024 --extern shared_dep=libshared_dep.so --crate-name mactwo mactwo/src/lib.rs
LD_LIBRARY_PATH=.:/home/greg/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/ rustc -C prefer-dynamic --crate-type bin --edition 2024 --extern macone=libmacone.so --extern mactwo=libmactwo.so --crate-name usertwo user/src/main.rs

I just took the path where I could find a libstd and added it (actually I think the exact libstd that turned up in some error message, but I can't seem to reproduce that error message). And I'm not sure I understand the potential fallout of there being two different copies of libstd here.

It turns out I'm not the first person to hit this though, ChromeOS hit it in rust-lang/rust#141958 and the suggestion was to do exactly what I ended up doing, adding rustc --print target-libdir (which returns the path I used on my system) to LD_LIBRARY_PATH. Of course that suggestion was justified by "this is what cargo also does" which is... apparently false.

So maybe the solution is just to use that path, and have a different libstd in proc macros from the one in rustc?

Alternatively since no one has hit the regression via cargo for ~a year now (and this bug report was discovery based on "I guess this should work" not existing code) I think cargo would be pretty justified in just turning this into an error. Especially if we aren't confident in the multple-libstds solution.