-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Problems with linking with system-wide installed libraries #16402
Comments
I talked with @brson about this yesterday, and we think that we should try out the following scheme:
The current behavior is a relic of an era since past, so it's certainly ripe for changing. |
Yes, this is reasonable solution. It would be nice if this would be implemented. |
According to me this should be marked as in need of a fix before the 1.0 release. |
I'm getting a similar error when trying to build with Steps to reproduce:
|
I am also getting this error. Is there a workaround ? |
@msierks, @bheesham: the workaround is installation of the Rust libraries not in the system location. You can use The first installation way is used e.g. here: https://github.com/Heather/gentoo-rust/tree/master/dev-lang/rust |
@jauhien: worked, thanks. |
rust-sdl2 recently transitioned into using pkg-config and now can't be compiled on OS X thanks to this issue, as both Rust and SDL2 (from Homebrew) are installed into /usr/local/lib by default and pkg-config passes in -L /usr/local/lib to rustc. Here's a gist with the exact error: https://gist.github.com/eagleflo/d6d7f446a66ed37d7869. |
Any new on this? Even the rust compiler itself cannot be compiled if it's already installed system-wide... |
In Debian's packaging solution for Rust they are not planning on installing Rust libraries globally, only Rust applications, so will not hit this problem. They will be packaging Rust libraries as source to a custom system location. When their package Rust applications are built, they will redirect cargo to look in that location for the source code to their dependencies, which will then be built and statically linked to the application. But the libraries will never be installed anywhere that could cause such a conflict. |
Please consider fixing this. It pops when trying to build statically linked programs that depend on libraries in |
I've just hit this bug with rustc 1.9.0-nightly (e91f889 2016-03-03): It looks like Rust is installing these libs twice and when I add
|
I ran into the same problem as snf with Rust 1.7 (clean install) and trying to build cassandra-sys-rs.
|
This can be "fixed" by using |
@MarkusJais did you find a fix for this? |
@MarkusJais using Ubuntu's native rustc / cargo packages over rustup.sh fixed this for me |
I get
This is apparently resolved by deleting the latter candidate. Is this going to cause issues for me later? Or is it a viable workaround? |
Same issue here. Tried to |
Triage: with the last comment here being a year and a half old, and with a lot of people seemingly having different but similar issues, and with many having fixed their issues, I'm going to give this one a close. If anyone on this thread is still having this problem today, please open a new bug with specific details, thanks. |
Short description
Rust linking system has one big problem now, that blocks possibility to have a given rust package to be installed and to be developed on the same system.
tl;dr: when you have a library installed system wide and you are developing package that contains this library (and uses other system wide installed libs) you'll have problems with linking because of
Example projects
Consider the minimal example, think we have those projects:
A library project looks like this:
A project with binary and library looks like this:
Steps to reproduce the error
I use 'image' directory as root here.
Compile and install hello_lib library
Compile and install hello_world project that uses hello_lib
Test if it works:
Continue developing of hello_world project and try to recompile it
Conclusions
So we have problem with current linking system. It is bad because
rustc
was installed to #13733I think that this issue can be solved if some algorithm that chooses which dynamic library to use depending on the order of -L flags is introduced to linking code. That means, e.g. use libraries found under the earliest -L path and ignore others.
The text was updated successfully, but these errors were encountered: