We're having some issues with requiring certain order for link-args commands and using -Zpre-link-args managed to meet our needs.
I was wondering why this is still considered nightly and if there's a tracking issue to stabilize it?
I assume it would hamper our ability to reorder link arguments when we make changes to the compiler. What exactly do you need it for?
It seems like when a build script emits:
[openssl-sys 0.9.106] cargo:rustc-link-search=native=/my/search/path
[openssl-sys 0.9.106] cargo:rustc-link-lib=dylib=ssl
[openssl-sys 0.9.106] cargo:rustc-link-lib=dylib=crypto
It gets turned into this: -lssl -lcrypto -L/my/search/path . The order being switched is not letting us dynamically link properly since the search path is added after the others.
My goal is for it to become -L/my/search/path -lssl -lcrypto
Using -Zpre-link-args allows me to additionally prepend the -L even earlier. I suppose this is running into a different bug anyways, but I can't seem to find a solution for that.
I also posted this in the discord: Discord
This seems relevant.
1 Like
That seems like a rustc bug to me. Rather than working around it with -Zpre-link-arg, please open an issue.
That is about preserving the -l vs -Clink-arg order, which is a lot harder to do than putting all -L before -l which should fix the issue of OP.
2 Likes
It was surprising that -L from build script. The Cargo code does appends -L first. Could you try nightly or beta and see which version still has this issue?
1 Like
@weihanglo - It looks like you found the fix! Looking at the commits, the fix was merged just days after we ran into the issue! Thank you so much!
The relevant commit fixing my issue: Search cargo build directories before system for libraries · rust-lang/cargo@6c6b34e · GitHub
1 Like