Make -L arguments given to linker always have the same order as the rustc -L arguments #16904
Conversation
|
Sorry for being a little slow to get to this, but this looks great! It would be very nice to have a test for a change such as this, and the easiest one that I can think of is to generate This would belong as a |
|
Thanks for the pointers. Added test under src/test/run-make/link-path-order. |
|
@alexcrichton: Hmm, that build failure can't be related to this patch, or? |
|
LLVM assertions are likely to reproduce though, sadly. Have you ensured that this builds on a 64-bit platform? |
This makes the extra library paths given to the gcc linker come in the same order as the -L options on the rustc command line.
inrustwetrust
force-pushed
the
link-path-order
branch
from
3743561
to
e7a000e
Compare
|
Oops, sorry. Didn't realize the new commits would show up automatically in the pull request as soon as I pushed them. The original patch was built on 64-bit Ubuntu and that LLVM assertion failure didn't show up then. Rebuilding after rebase now to see if I can reproduce it against the current trunk code. |
|
Hmm, cannot reproduce this issue on 64-bit Ubuntu. I don't have a Mac available to test on, I'm afraid. |
|
Let's try again and see what happens! |
…hton
Issue can be reproduced by the following:
```
$ cat main.rs
fn main() {}
$ rustc -Z print-link-args -Lfoo -Lbar main.rs
```
Run the rustc command a few times and observe that the order of the '-L' 'foo' '-L' 'bar' options randomly changes.
Actually hit this issue in practice on Windows when specifying two -L directories to rustc, one with rust-sdl2 in it and one with the C SDL2.dll. Since Windows file systems aren't case-sensitive, gcc randomly attempted to link against the rust sdl2.dll instead of SDL2.dll if that -L directory happened to come first.
The randomness was due to addl_lib_search_paths being a HashSet. Changed it to a Vec instead which maintains the ordering.
Unsure how to test this though since it is random by nature; suggestions very welcome.
internal: Bump rust-cache action Fixes a Node 16 deprecation warning and also pulls in Swatinem/rust-cache#147, which sounds interesting.
Issue can be reproduced by the following:
Run the rustc command a few times and observe that the order of the '-L' 'foo' '-L' 'bar' options randomly changes.
Actually hit this issue in practice on Windows when specifying two -L directories to rustc, one with rust-sdl2 in it and one with the C SDL2.dll. Since Windows file systems aren't case-sensitive, gcc randomly attempted to link against the rust sdl2.dll instead of SDL2.dll if that -L directory happened to come first.
The randomness was due to addl_lib_search_paths being a HashSet. Changed it to a Vec instead which maintains the ordering.
Unsure how to test this though since it is random by nature; suggestions very welcome.