Skip to content

Use Rust in the Windows CI jobs #2213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dscho wants to merge 4 commits into
base: js/mingw-build-updates
Choose a base branch
from
+50 −5
Open

Use Rust in the Windows CI jobs #2213

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b6a094d
rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
dscho Jun 11, 2026
6754d49
ci(windows): build with Rust
dscho Aug 31, 2026
12f6474
amend! rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
dscho Sep 12, 2026
ec90274
fixup! rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
dscho Sep 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions .github/workflows/main.yml
View file
Open in desktop

@Edgarruiz8585 Edgarruiz8585 Sep 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{Edgar_Manuel_Ruiz_Arias_217596670, title={Edgar Manuel Ruiz Arias mr ed}, journal=

Original file line number Diff line number Diff line change
Expand Up @@ -114,6 +114,30 @@ jobs:
steps:
- uses: actions/checkout@v6
- uses: git-for-windows/setup-git-for-windows-sdk@v2
- name: Install GCC-compatible Rust target
shell: bash
run: |
# The hosted Windows runners ship a rustup-managed Rust whose
# default toolchain targets the MSVC ABI. That produces a
# `gitcore.lib` which the MinGW GCC used by the rest of the
# build cannot link. Install the precompiled `std` for a
# GCC-compatible target triple matching the MSYS2 subsystem;
# the Makefile selects the same triple via $(MSYSTEM) and
# passes it to `cargo build --target`.
case "$MSYSTEM" in
CLANGARM64) target=aarch64-pc-windows-gnullvm ;;
CLANG64) target=x86_64-pc-windows-gnullvm ;;
CLANG32) target=i686-pc-windows-gnullvm ;;
UCRT64) target=x86_64-pc-windows-gnu ;;
MINGW64) target=x86_64-pc-windows-gnu ;;
MINGW32) target=i686-pc-windows-gnu ;;
*) echo "::error::Unsupported MSYSTEM: $MSYSTEM"; exit 1 ;;
esac &&
rustup target add "$target" &&

# Ensure that cargo.exe is found even with the minimal SDK's restricted PATH
CARGO="$(type -p cargo.exe)" &&
echo "export PATH=\$PATH:${CARGO%/cargo.exe}" >>/etc/profile
- name: build
shell: bash
env:
Expand Down
3 changes: 2 additions & 1 deletion Makefile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -959,7 +959,7 @@ RUST_LIB_NAME = gitcore.lib
else

@gitgitgadget gitgitgadget Bot Sep 2, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> +                ifneq (,$(filter %ARM64, $(MSYSTEM)))
> +			HOST_CPU = aarch64
> +                else ifneq (,$(filter %32, $(MSYSTEM)))
> +			HOST_CPU = i686
> +                else
> +			HOST_CPU = x86_64
> +                endif
> +                ifneq (,$(filter CLANG%, $(MSYSTEM)))
> +			CARGO_TARGET = $(HOST_CPU)-pc-windows-gnullvm
> +                else
> +			CARGO_TARGET = $(HOST_CPU)-pc-windows-gnu
> +                endif

Assuming HOST_CPU is x86_64 in the above, as UCRT64, unlike
CLANG{ARM64,64,32}, does not match CLANG%, I presume that the above
gives "x86_64-pc-windows-gnu" to builds with MSYSTEM set to UCRT64.

There is this "we only need MINGW64 but the switch to UCRT64 is
imminent, and others are for documentation" part we see in the
[PATCH 2/2]

+        case "$MSYSTEM" in
+        CLANGARM64) target=aarch64-pc-windows-gnullvm ;;
+        CLANG64)    target=x86_64-pc-windows-gnullvm  ;;
+        CLANG32)    target=i686-pc-windows-gnullvm    ;;
+        UCRT64)     target=x86_64-pc-windows-gnullvm  ;;
+        MINGW64)    target=x86_64-pc-windows-gnu      ;;
+        MINGW32)    target=i686-pc-windows-gnu        ;;
+        *) echo "::error::Unsupported MSYSTEM: $MSYSTEM"; exit 1 ;;
+        esac &&
+        rustup target add "$target" &&

that maps UCRT64 to "x86_64-pc-windows-gnullvm"

I do not know if it is intended.  If so, please ignore.

Thanks.

@gitgitgadget gitgitgadget Bot Sep 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Johannes Schindelin wrote on the Git mailing list (how to reply to this email):

Hi Junio,

On Tue, 1 Sep 2026, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > +                ifneq (,$(filter %ARM64, $(MSYSTEM)))
> > +			HOST_CPU = aarch64
> > +                else ifneq (,$(filter %32, $(MSYSTEM)))
> > +			HOST_CPU = i686
> > +                else
> > +			HOST_CPU = x86_64
> > +                endif
> > +                ifneq (,$(filter CLANG%, $(MSYSTEM)))
> > +			CARGO_TARGET = $(HOST_CPU)-pc-windows-gnullvm
> > +                else
> > +			CARGO_TARGET = $(HOST_CPU)-pc-windows-gnu
> > +                endif
> 
> Assuming HOST_CPU is x86_64 in the above, as UCRT64, unlike
> CLANG{ARM64,64,32}, does not match CLANG%, I presume that the above
> gives "x86_64-pc-windows-gnu" to builds with MSYSTEM set to UCRT64.

Correct.

> There is this "we only need MINGW64 but the switch to UCRT64 is
> imminent, and others are for documentation" part we see in the
> [PATCH 2/2]
> 
> +        case "$MSYSTEM" in
> +        CLANGARM64) target=aarch64-pc-windows-gnullvm ;;
> +        CLANG64)    target=x86_64-pc-windows-gnullvm  ;;
> +        CLANG32)    target=i686-pc-windows-gnullvm    ;;
> +        UCRT64)     target=x86_64-pc-windows-gnullvm  ;;
> +        MINGW64)    target=x86_64-pc-windows-gnu      ;;
> +        MINGW32)    target=i686-pc-windows-gnu        ;;
> +        *) echo "::error::Unsupported MSYSTEM: $MSYSTEM"; exit 1 ;;
> +        esac &&
> +        rustup target add "$target" &&
> 
> that maps UCRT64 to "x86_64-pc-windows-gnullvm"
> 
> I do not know if it is intended.  If so, please ignore.

Since UCRT64 is still using GCC, it should be `-gnu`. Thanks for catching.

Ciao,
Johannes

@gitgitgadget gitgitgadget Bot Sep 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> @@ -993,6 +993,7 @@ endif
>  ifndef DEBUG
>  CARGO_ARGS += --release
>  endif
> +CARGO_ARGS += $(if $(CARGO_TARGET),--target $(CARGO_TARGET))

Should this use CARGO_BUILD_TARGET (instead of CARGO_TARGET) to
match what the officially supported Cargo environment variable is
called?  It would also help us work better with the changes from the
jc/rust-cargo-build-target topic.

Thanks.

Author: James Le Cuirot <chewi@gentoo.org>
Date:   Thu Sep 10 11:20:14 2026 +0100

    rust: respect CARGO_BUILD_TARGET when locating build output
    
    When cross-compiling, Cargo always writes to a target-tuple subdirectory
    determined by CARGO_BUILD_TARGET, even when it matches the native tuple.
    The build looked in $BUILD_DIR/$BUILD_TYPE directly, so it failed to
    locate the freshly built library.
    
    Respect CARGO_BUILD_TARGET in the output path so the correct artifact
    is located.
    
    Signed-off-by: James Le Cuirot <chewi@gentoo.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Makefile b/Makefile
index d4b775953d..f0ca2e4f72 100644
--- a/Makefile
+++ b/Makefile
@@ -959,7 +959,7 @@ RUST_LIB_NAME = gitcore.lib
 else
 RUST_LIB_NAME = libgitcore.a
 endif
-RUST_LIB = target/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
+RUST_LIB = target/$(if $(CARGO_BUILD_TARGET),$(CARGO_BUILD_TARGET)/)$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
 endif
 
 GITLIBS = common-main.o $(LIB_FILE)
diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh
index 75f3cd1265..83c7e7b79b 100755
--- a/src/cargo-meson.sh
+++ b/src/cargo-meson.sh
@@ -38,7 +38,7 @@ then
 	exit $RET
 fi
 
-if ! cmp "$BUILD_DIR/$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a" >/dev/null 2>&1
+if ! cmp "$BUILD_DIR/${CARGO_BUILD_TARGET:+$CARGO_BUILD_TARGET/}$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a" >/dev/null 2>&1
 then
-	cp "$BUILD_DIR/$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a"
+	cp "$BUILD_DIR/${CARGO_BUILD_TARGET:+$CARGO_BUILD_TARGET/}$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a"
 fi

@gitgitgadget gitgitgadget Bot Sep 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

James Le Cuirot wrote on the Git mailing list (how to reply to this email):

On Fri, 2026-09-11 at 14:09 -0700, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > @@ -993,6 +993,7 @@ endif
> >  ifndef DEBUG
> >  CARGO_ARGS += --release
> >  endif
> > +CARGO_ARGS += $(if $(CARGO_TARGET),--target $(CARGO_TARGET))
> 
> Should this use CARGO_BUILD_TARGET (instead of CARGO_TARGET) to
> match what the officially supported Cargo environment variable is
> called?  It would also help us work better with the changes from the
> jc/rust-cargo-build-target topic.
> 
> Thanks.

Yes, without explicitly setting --target at all. This is how Gentoo Linux
supports cross-compiling of its Rust packages. Just avoid setting
CARGO_BUILD_TARGET (or passing --target) when you're not cross-compiling. It
will cause Cargo to behave differently, even if you give the native tuple. For
example, RUSTFLAGS is normally applied to both the build host binaries and the
target host binaries, but when an explicit target is set, RUSTFLAGS is only
applied to the target host binaries.

Regards,
Chewi

> Author: James Le Cuirot <chewi@gentoo.org>
> Date:   Thu Sep 10 11:20:14 2026 +0100
> 
>     rust: respect CARGO_BUILD_TARGET when locating build output
>     
>     When cross-compiling, Cargo always writes to a target-tuple subdirectory
>     determined by CARGO_BUILD_TARGET, even when it matches the native tuple.
>     The build looked in $BUILD_DIR/$BUILD_TYPE directly, so it failed to
>     locate the freshly built library.
>     
>     Respect CARGO_BUILD_TARGET in the output path so the correct artifact
>     is located.
>     
>     Signed-off-by: James Le Cuirot <chewi@gentoo.org>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
> 
> diff --git a/Makefile b/Makefile
> index d4b775953d..f0ca2e4f72 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -959,7 +959,7 @@ RUST_LIB_NAME = gitcore.lib
>  else
>  RUST_LIB_NAME = libgitcore.a
>  endif
> -RUST_LIB = target/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
> +RUST_LIB = target/$(if $(CARGO_BUILD_TARGET),$(CARGO_BUILD_TARGET)/)$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
>  endif
>  
>  GITLIBS = common-main.o $(LIB_FILE)
> diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh
> index 75f3cd1265..83c7e7b79b 100755
> --- a/src/cargo-meson.sh
> +++ b/src/cargo-meson.sh
> @@ -38,7 +38,7 @@ then
>  	exit $RET
>  fi
>  
> -if ! cmp "$BUILD_DIR/$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a" >/dev/null 2>&1
> +if ! cmp "$BUILD_DIR/${CARGO_BUILD_TARGET:+$CARGO_BUILD_TARGET/}$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a" >/dev/null 2>&1
>  then
> -	cp "$BUILD_DIR/$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a"
> +	cp "$BUILD_DIR/${CARGO_BUILD_TARGET:+$CARGO_BUILD_TARGET/}$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a"
>  fi

RUST_LIB_NAME = libgitcore.a
endif
RUST_LIB = target/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
RUST_LIB = target$(if $(CARGO_BUILD_TARGET),/$(CARGO_BUILD_TARGET))/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
endif

GITLIBS = common-main.o $(LIB_FILE)
Expand Down Expand Up @@ -993,6 +993,7 @@ endif
ifndef DEBUG
CARGO_ARGS += --release
endif
CARGO_ARGS += $(if $(CARGO_BUILD_TARGET),--target $(CARGO_BUILD_TARGET))

# For the 'sparse' target
SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
Expand Down
3 changes: 0 additions & 3 deletions ci/lib.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -391,9 +391,6 @@ linux-asan-ubsan)
osx-meson)
MESONFLAGS="$MESONFLAGS -Dcredential_helpers=osxkeychain"
;;
windows-*)
export NO_RUST=UnfortunatelyYes
;;
esac

MAKEFLAGS="$MAKEFLAGS CC=${CC:-cc}"
Expand Down
25 changes: 24 additions & 1 deletion config.mak.uname
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -758,7 +758,30 @@ ifeq ($(uname_S),MINGW)
MINGW_PREFIX := /$(shell echo '$(MSYSTEM)' | tr A-Z a-z)
endif
prefix = $(MINGW_PREFIX)
HOST_CPU = $(patsubst %-w64-mingw32,%,$(MINGW_CHOST))

# A rustup-managed Rust on Windows defaults to the MSVC ABI and
# produces a `gitcore.lib` that the MinGW `ld.exe` cannot link.
# Pick a GCC-compatible Rust target triple matching the MSYS2
# subsystem instead: `*-pc-windows-gnullvm` for the Clang/LLVM
# subsystems (which on Windows is also the only choice for
# ARM64, where no MinGW-GCC port exists) and `*-pc-windows-gnu`
# for the MSVCRT-based MinGW subsystems. For a `staticlib`
# crate-type Cargo does not invoke an external linker, so
# `rustup target add <triple>` is sufficient.
ifneq (,$(filter %ARM64, $(MSYSTEM)))
HOST_CPU = aarch64
else ifneq (,$(filter %32, $(MSYSTEM)))
HOST_CPU = i686
else
HOST_CPU = x86_64
endif
ifneq (,$(filter CLANG%, $(MSYSTEM)))
CARGO_BUILD_TARGET = $(HOST_CPU)-pc-windows-gnullvm
else
CARGO_BUILD_TARGET = $(HOST_CPU)-pc-windows-gnu
endif
export CARGO_BUILD_TARGET

BASIC_LDFLAGS += -Wl,--pic-executable
COMPAT_CFLAGS += -DDETECT_MSYS_TTY \
-DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" \
Expand Down
Loading