Tracking Issue for linker arguments respecting their relative order with `-l` library options

[petrochenkov]

This is a tracking issue for link arguments respecting their relative order with -l library options, which is a part of RFC "Linking modifiers for native libraries" (#81490, rust-lang/rfcs#2951), https://github.com/rust-lang/rfcs/blob/master/text/2951-native-link-modifiers.md#relative-order-of--l-and--clink-args-options specifically.
There's no feature gate for the issue.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC - flag '-l link-arg=___ was added #99467
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

The feature is unlikely to be implementable in the form that is specified in the RFC, i.e. by preserving relative order of -l and -Clink-arg(s) options.
-C link-arg was usable for overriding options previously passed by the compiler for long time, so is pretty much guaranteed to be passed at the end of command line at this point.

The suggested solution (see #81490 and below) is to reuse the -l option for such arguments and introduce -l link-arg=arbitrary-link-argument, which is exactly like -C link-arg=arbitrary-link-argument, except that its relative order to other -l options is respected.

Implementation history

• flag '-l link-arg=___ was added #99467
• Added linker_arg(s) Linker trait methods for link-arg to be prefixed "-Wl," for cc-like linker args and not verbatim #118202

[petrochenkov]

Implemented in #99467.

[petrochenkov]

There's one possible improvement to -l link-arg making it more portable between linkers and useful - befriending it with the verbatim modifier (#99425).

-l link-arg:-verbatim=-foo would add -Wl,-foo (or equivalent) when C compiler is used as a linker, and just -foo when bare linker is used.
-l link-arg:+verbatim=-bar on the other hand would always pass just -bar.
Not sure about the default here, I suspect that -verbatim would be preferable, but it's different from -C link-arg.

This would help to make link-arg usable in #[link] attributes and e.g. wrap libc and libgcc into a group (*) in the libc crate like

#[link(kind = "link-arg", name = "--start-group")]
#[link(kind = "static", name = "c")]
#[link(kind = "static", name = "gcc")]
#[link(kind = "link-arg", name = "--end-group")]

(*) to address cyclic dependencies between them

This is an analogue of CMake's LINKER: prefix (https://cmake.org/cmake/help/git-stage/command/target_link_options.html#handling-compiler-driver-differences), and was discussed as a possible future extension in the link modifier RFC (https://github.com/rust-lang/rfcs/blob/master/text/2951-native-link-modifiers.md#support-linkarg--string-in-addition-to-the-modifiers).

cc @krasimirgg

[Be-ing]

I think -l link-arg may have an unintended side effect: when build scripts run println!("cargo:rustc-link-lib={some_value}") to get cargo to call rustc with -l, cargo transitively passes the -l some_value down to the crates' reverse dependencies. By contrast, using the recently stabilized cargo:rustc-link-arg, which passes -C link-arg to rustc, cargo does not pass the linker argument down to reverse dependencies. I think this would be useful, but is this desired?