-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot open shared object file libstd.so, in bin crate that transitively depends on libproc_macro #4651
Comments
This is sort of to be expected, and there's not really anything we can do about it. When running through cargo/rustup we can manage lookup paths, but otherwise the generated binary has no way of finding the libraries itself :( |
Thanks, I see why that goes wrong. I will try to work around it. |
@alexcrichton I'm experiencing a similar issue during a cross-build but not when compiling for the host (the |
@dtolnay I've found your workaround. Does it eliminate the |
@drozdziak1 that likely indicates that the |
@alexcrichton it may be desirable to have cargo copy |
When building a binary crate with a transitive dependency on libproc_macro,
cargo run
is able to run successfully but the resulting binary cannot be run directly.Repro script
Output
In this minimized repro, the bin crate depends directly on libproc_macro. As reported in dtolnay/indoc#15, this also fails if libproc_macro is a dependency of a dependency (proc-macro-hack) of a dependency (indoc) of a dependency (lasso), which is more realistic.
@glennpierce
The text was updated successfully, but these errors were encountered: