Stabilize -Cdlltool

[dpaoliello]

As a prerequisite to stabilizing raw-dylib (tracking: #58713) the -Zdlltool argument (that permits a user to specify a custom location for the dlltool executable that is used to generate import libraries on windows-gnu targets) also needs to be stabilized so that users don't need to reach for an unstable option to configure a stable feature.

Changes:

• Stabilized the argument as -Cdlltool.
• Note the path to dlltool if invoking it failed (we don't need to do this if dlltool returns an error since it prints its path in the error message).
• Adds tests for -Cdlltool.
• Adds tests for being unable to find the dlltool executable, and dlltool failing.
• Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to stderr.
• If dlltool returns an error only print its stderr as stdout doesn't contain anything interesting (and using \n in the messages.ftl file doesn't work).

NOTE: As previously noted (#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: #104218 (comment)

[rustbot]

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

[dpaoliello]

r? @michaelwoerister

[michaelwoerister]

Can you replace (windows-gnu only) with (ignored except when targeting windows-gnu). I think that's more clear.

[michaelwoerister]

Thanks, @dpaoliello, looks great!

What do you think about extending this PR to also stabilize raw-dylibs on x86? Or are there any blockers for that left?

Since we'll need an FCP for this anyway, we could take care of x86 too.

[petrochenkov]

Are there any interactions with -Clink-self-contained here?
Do we ship dlltool with Rust toolchain or it's always found somewhere else on the system?

[mati865]

Do we ship dlltool with Rust toolchain or it's always found somewhere else on the system?

We do:

rust/src/bootstrap/dist.rs

Line 205 in 553ecbe

let target_tools = [compiler, "ld.exe", "dlltool.exe", "libwinpthread-1.dll"];

but I don't remember more details.

[dpaoliello]

Are there any interactions with -Clink-self-contained here?

Currently no. Given the wording of that argument is this flag controls whether the linker will use libraries and objects shipped with Rust instead or those in the system I wouldn't expect it to either (since dlltool is a tool used by the compiler, rather than an object or library that is linked in). One could argue that it should also cover the tools used by the compiler, but I feel like that's out-of-scope for this change (since it would affect how other tools are discovered).

Do we ship dlltool with Rust toolchain or it's always found somewhere else on the system?

dlltool ships with the pc-windows-gnu rustc component if the dist.include-mingw-linker option is set (which it is by default): #108581

[dpaoliello]

Thanks, @dpaoliello, looks great!

What do you think about extending this PR to also stabilize raw-dylibs on x86? Or are there any blockers for that left?

Since we'll need an FCP for this anyway, we could take care of x86 too.

There are no more blockers that I know of: I'll merge this with the x86 stabilization for raw-dylib and create a new PR.

[dpaoliello]

Closing in favor of stabilizing the entire raw-dylib feature: #109677

[petrochenkov]

@dpaoliello

One could argue that it should also cover the tools used by the compiler

Yeah, that's exactly the plan, see the discussion on #96884.
I need to check how the search for dlltool is currently happening, but we'll likely be able to make the -Cself-contained changes in a backward compatible manner anyway.

[dpaoliello]

@dpaoliello

One could argue that it should also cover the tools used by the compiler

Yeah, that's exactly the plan, see the discussion on #96884. I need to check how the search for dlltool is currently happening, but we'll likely be able to make the -Cself-contained changes in a backward compatible manner anyway.

Currently we search for dlltool by walking the PATH (

rust/compiler/rustc_codegen_llvm/src/back/archive.rs

Line 432 in dd19135

fn find_binutils_dlltool(sess: &Session) -> OsString {

), so it should be possible to add a check in there for -Cself-contained and redirect to a "known" location.