Customize the MinGW-w64 dlltool program name

[richli]

Currently, the dlltool program from MinGW-w64 is set to a hard-coded constant (namely, x86_64-w64-mingw32-dlltool for the 64-bit version). Would it be feasible to allow a custom name, such as by checking for an environment variable?

The motivation here is that Fedora 37 will be adding support for the MinGW-w64 UCRT toolchain. Thus, the new ucrt64-binutils package has /usr/bin/x86_64-w64-mingw32ucrt-dlltool.

As a quick hack to check that it works, I replaced the constant and was able to successfully build a .pyd using the UCRT:

sed -i -e 's/x86_64-w64-mingw32-dlltool/x86_64-w64-mingw32ucrt-dlltool/' $HOME/.cargo/registry/src/github.com-*/python3-dll-a-0.2.5/src/lib.rs

(My first approach was to create a link from /usr/bin/x86_64-w64-mingw32ucrt-dlltool to /usr/bin/x86_64-w64-mingw32-dlltool, but for some reason it doesn't work.)

[ravenexp]

It's interesting, how does rustc itself know it has to use x86_64-w64-mingw32ucrt-gcc in place of x86_64-w64-mingw32-gcc for linking? There is a separate x86_64-uwp-windows-gnu rustc target, but I doubt that's what Fedora is using because it's only tier 3.

Instead of adding an new environment variable tweak, I'd rather try to find out what tool prefix rustc is using for the target and use that. I just have no idea where to start...

[richli]

Oh, for the linking, I did have to override that using the target.x86_64-pc-windows-gnu.linker Cargo setting. Here's a Dockerfile to reproduce everything:

FROM quay.io/fedora/fedora:37

RUN dnf install -y gcc ucrt64-gcc ucrt64-winpthreads-static
RUN curl --proto "=https" --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --target x86_64-pc-windows-gnu

WORKDIR /root
RUN python3 -m venv --upgrade-deps venv

ENV PATH="/root/.cargo/bin:/root/venv/bin:${PATH}"
RUN pip install maturin
RUN maturin new -b pyo3 ucrt-test

WORKDIR /root/ucrt-test
RUN cargo add pyo3@0.16.5 -F abi3-py38,generate-import-lib

# To ensure python3-dll-a is downloaded before rewriting the dlltool constant
RUN cargo fetch

RUN sed -i -e 's/x86_64-w64-mingw32-dlltool/x86_64-w64-mingw32ucrt-dlltool/' "$HOME"/.cargo/registry/src/github.com-*/python3-dll-a-0.2.5/src/lib.rs

# Build the wheel
ENV CARGO_TARGET_X86_64_PC_WINDOWS_GNU_LINKER=x86_64-w64-mingw32ucrt-gcc
RUN maturin build --target x86_64-pc-windows-gnu

# Extract the .pyd file and verify that it doesn't use msvcrt.dll
RUN unzip target/wheels/ucrt_test-0.1.0-cp38-abi3-win_amd64.whl ucrt_test/ucrt_test.pyd
RUN mingw-objdump -p ucrt_test/ucrt_test.pyd  | grep DLL

Answering your question about the default linker name for the x86_64-pc-windows-gnu target: it's x86_64-w64-mingw32-gcc:

https://github.com/rust-lang/rust/blob/1.62.1/compiler/rustc_target/src/spec/x86_64_pc_windows_gnu.rs#L13

[ravenexp]

PyO3 can be updated to parse CARGO_TARGET_X86_64_PC_WINDOWS_GNU_LINKER, but this will not work when the linker is defined in the cargo config file. There also is rustc --print target-spec-json, but it is still unstable.

Maybe adding a new env variable like PYO3_CROSS_DLLTOOL can be added, but this will also require updating PyO3 documentation. I'll look into this next week.

[ravenexp]

Sorry for the wait, the fix was released as v0.2.6.

Try setting PYO3_MINGW_DLLTOOL environment variable to x86_64-w64-mingw32ucrt-dlltool.