-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Native libraries for the local crate linked in the wrong order #28595
Labels
A-linkage
Area: linking into static, shared libraries and binaries
Comments
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Sep 23, 2015
This commit swaps the order of linking local native libraries and upstream native libraries on the linker command line. Detail of bugs this can cause can be found in rust-lang#28595, and this change also invalidates the test case that was added for rust-lang#12446 which is now considered a bug because the downstream dependency would need to declare that it depends on the native library somehow. Closes rust-lang#28595
Should we crater this? Sounds frightening. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Oct 1, 2015
This commit swaps the order of linking local native libraries and upstream native libraries on the linker command line. Detail of bugs this can cause can be found in rust-lang#28595, and this change also invalidates the test case that was added for rust-lang#12446 which is now considered a bug because the downstream dependency would need to declare that it depends on the native library somehow. Closes rust-lang#28595
bors
added a commit
that referenced
this issue
Oct 1, 2015
This commit swaps the order of linking local native libraries and upstream native libraries on the linker command line. Detail of bugs this can cause can be found in #28595, and this change also invalidates the test case that was added for #12446 which is now considered a bug because the downstream dependency would need to declare that it depends on the native library somehow. Closes #28595 [breaking-change]
larsbergstrom
referenced
this issue
in vvuk/skia
Oct 15, 2015
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
There's currently a large comment in the compiler explaining how we link artifacts in this order:
It also explicitly mentions why 2/3 are a little backwards.
Unfortunately, however, it looks like the ordering above causes link errors in otherwise correct situations. For example let's consider (code example at the end of this issue)
The ordering of flags on the command line will be:
The problem here is that libB is contained in B's rlib, so the ordering of the linker is incorrect, libA shows up after libB. This will cause a linker error if the object file doesn't otherwise reference symbols from B's rlib.
I think that the wording for why steps 2/3 above are swapped is far out of date by this point (with Cargo build scripts and modern methods to link native libraries), so it sounds to me like they should be swapped now. This may cause breakage, but it should always be fixable by restructuring the DAG to more accurately reflect the network of dependencies between C libraries and Rust crates.
The text was updated successfully, but these errors were encountered: