redundant linker flag warning is wrong and breaks linking #47989
Comments
Mark-Simulacrum
added
A-linkage
|
This is somewhat not trivial to fix as we don't know whether a given There are also to an extent some backwards compatibility concerns here. |
|
Could we perhaps at least add some option to ignore this? |
|
I was recently bitten by this bug, trying to link multiple internal helper C++ libraries into a Rust executable. I was able to put together a minimal repro: on Linux, one of the subpackages builds successfully, and one gets linker errors, and the only difference between the two is the order in which the helper libraries are built and added to the linker command line. |
dcreager
added a commit
to dcreager/rust
that referenced
this issue
Dec 20, 2018
When a library (L1) is passed to the linker multiple times, this is
sometimes purposeful: there might be several other libraries in the
linker command (L2 and L3) that all depend on L1. You'd end up with a
(simplified) linker command that looks like:
-l2 -l1 -l3 -l1
With the previous behavior, when rustc encountered a redundant library,
it would keep the first instance, and remove the later ones, resulting
in:
-l2 -l1 -l3
This can cause a linker error, because on some platforms (e.g. Linux),
the linker will only include symbols from L1 that are needed *at the
point it's referenced in the command line*. So if L3 depends on
additional symbols from L1, which aren't needed by L2, the linker won't
know to include them, and you'll end up with "undefined symbols" errors.
A better behavior is to keep the *last* instance of the library:
-l2 -l3 -l1
This ensures that all "downstream" libraries have been included in the
linker command before the "upstream" library is referenced.
Fixes rust-lang#47989
|
I wrote up a potential fix in #57018. We'd still remove redundant |
|
@dcreager It still says "redundant linker flag specified for library stdc++". |
bors
added a commit
that referenced
this issue
Mar 20, 2019
Keep last redundant linker flag, not first When a library (L1) is passed to the linker multiple times, this is sometimes purposeful: there might be several other libraries in the linker command (L2 and L3) that all depend on L1. You'd end up with a (simplified) linker command that looks like: ``` -l2 -l1 -l3 -l1 ``` With the previous behavior, when rustc encountered a redundant library, it would keep the first instance, and remove the later ones, resulting in: ``` -l2 -l1 -l3 ``` This can cause a linker error, because on some platforms (e.g. Linux), the linker will only include symbols from L1 that are needed *at the point it's referenced in the command line*. So if L3 depends on additional symbols from L1, which aren't needed by L2, the linker won't know to include them, and you'll end up with "undefined symbols" errors. A better behavior is to keep the *last* instance of the library: ``` -l2 -l3 -l1 ``` This ensures that all "downstream" libraries have been included in the linker command before the "upstream" library is referenced. Fixes #47989
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If one passes the same
-lfoooption twice to rustc it warnsredundant linker flag specified for library `foo`and ignores the second argument. Linkers are sensitive to the order of their arguments and passing the same argument twice is common and sometimes necessary to get a program to link correctly.In fact, rustc itself passes the linker (cleaned up a bit)
-ldl -lrt -lpthread -lpthread -lgcc_s -lc -lm -lrt -lpthread -lutil -lutil, which includes four "redundant" linker flags (at least two of which are actually redundant, to be fair).The text was updated successfully, but these errors were encountered: