-
Notifications
You must be signed in to change notification settings - Fork 12.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
Include deduced locations for native libraries in rpath #2397
Comments
This is really not something that should be done, installed libraries will already be in the search path. Using rpath is very fragile and won't survive changes to the system configuration. |
A particular problem here is native libraries that are part of the build. See here and here for an example: not only do I have to use -L and LD_LIBRARY_PATH for a library that the test crate should have no logical visibility for, I have to also explicitly bring it in as an external module. Of course I could choose to build an install the tiny support library as a separate project, but it's annoying to have to do this. In the C land, we've long had libtool and similar solutions to take care of it. |
closing as we have strong feedback that rpath is undesirable; we can approach along other avenues (static linking + use of workspace lib paths) |
Given that Regardless of the decision ultimately made here, I think the nuances of this behavior should be documented in the Just for reference, the mentioned rust/compiler/rustc_codegen_ssa/src/back/link.rs Lines 1614 to 1616 in c5ecc15
|
only do env var cleanup if all threads have stopped Hopefully fixes rust-lang/miri#2396
From a FIXME in
back::link
:The text was updated successfully, but these errors were encountered: