-
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
Regression in running tests with custom library search path #4044
Comments
Cargo was tweaked to not modify |
In my case, the library is outside the build directory. What was the reason for this tweak? Are there any downsides in the old behavior? |
This was changed in #3651 which has some linked discussion for where this can go awry. |
Did the issue fixed by #3651 also occur on Windows and Linux or was it a Mac exclusive issue? If it's the latter, then why did we change the behavior on Windows and Linux to break existing setups? Frankly, I find it odd that we still conflate directories needed at link time with directories needed at run time. If we created a new |
I got bitten by this today.
Changing the LD_LIBRARY_PATH before running did fix the problem. |
As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it. I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect? The team would be especially grateful if such a comment included details such as:
Thank you for contributing! (The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.) If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable! |
This issue should remain open until a team member definitely tells us the current behavior is the correct one. And i seriously dislike the stale bot. |
Thanks for opening this issue. I have a library named Rutie and I've found that Rust isn't acknowledging linker paths on Rust but it is on Mac… see this issue I opened rust-lang/rust#57550 In the meantime I either symlink or copy the Ruby dynamic library to the
Following your advice here; setting So now I'm going to experiment in how to make this behavior work with Rutie automatically without requiring user's of my crate to go through this same process. |
Rust's C linker arguments don't work as they should. See issue rust-lang/cargo#4044 (comment) for more details on this. Hopefully in the future C linker arguments and library paths will improve.
I've run into this issue where If you want to try this, it's this commit: open-quantum-safe/liboqs-rust@ef05887
fails;
works. |
Steps to reproduce:
cargo:rustc-link-search=native=
.cargo test
.cargo 0.17 (shipped with rust 1.16.0) successfully runs the test because it adds the library path to
LD_LIBRARY_PATH
(on Linux).But cargo 0.18 (shipped with rust 1.17.0) fails to run the test:
It doesn't add the library path to
LD_LIBRARY_PATH
anymore. The binary is linked successfully because cargo probably still supplies the path to the linker, but it's not enough to run the binary.The text was updated successfully, but these errors were encountered: