All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Patrick Steinhardt <ps@pks.im>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: [PATCH 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
Date: Tue, 01 Sep 2026 14:21:48 +0000	[thread overview]
Message-ID: <2b7f58a037592325c2cb9b52bf8f1ef434bd6202.1788272509.git.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.2213.git.1788272509.gitgitgadget@gmail.com>

From: Johannes Schindelin <johannes.schindelin@gmx.de>

When Git is built under MSYS2/MinGW with Rust support enabled, the
Makefile expects `cargo build` to drop a `target/release/libgitcore.a`
that is linkable by the same MinGW GCC used for every other object.
With Rust installed via `rustup` (the way it ships on the
GitHub-hosted `windows-2022` and `windows-11-arm` runners that build
microsoft/git), the default toolchain targets the MSVC ABI; cargo
then writes `target/release/gitcore.lib` instead, which the MinGW
`ld.exe` cannot consume:

    LINK git-shell.exe
    D:\git-sdk-64-minimal\mingw64\bin/ld.exe: cannot find target/release/libgitcore.a: No such file or directory
    collect2.exe: error: ld returned 1 exit status

See https://github.com/microsoft/git/actions/runs/27341625000 for the
full log.

Let's define the correct target. Re-use (and fix) the existing
`HOST_CPU` variable for that purpose. Avoid relying on environment
variables that are simply not defined in Git for Windows' minimal SDK
that Git uses in its CI runs.

Assisted-by: Claude Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Makefile         |  3 ++-
 config.mak.uname | 24 +++++++++++++++++++++++-
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index fac3e8879c..bf2a11c08a 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_TARGET),/$(CARGO_TARGET))/$(RUST_BUILD_CONFIG)/$(RUST_LIB_NAME)
 endif
 
 GITLIBS = common-main.o $(LIB_FILE)
@@ -993,6 +993,7 @@ endif
 ifndef DEBUG
 CARGO_ARGS += --release
 endif
+CARGO_ARGS += $(if $(CARGO_TARGET),--target $(CARGO_TARGET))
 
 # For the 'sparse' target
 SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__
diff --git a/config.mak.uname b/config.mak.uname
index 0b63be10b7..720d9ba3ed 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -758,7 +758,29 @@ 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_TARGET = $(HOST_CPU)-pc-windows-gnullvm
+                else
+			CARGO_TARGET = $(HOST_CPU)-pc-windows-gnu
+                endif
+
 		BASIC_LDFLAGS += -Wl,--pic-executable
 		COMPAT_CFLAGS += -DDETECT_MSYS_TTY \
 			-DENSURE_MSYSTEM_IS_SET="\"$(MSYSTEM)\"" \
-- 
gitgitgadget


  reply	other threads:[~2026-09-01 14:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 14:21 [PATCH 0/2] Use Rust in the Windows CI jobs Johannes Schindelin via GitGitGadget
2026-09-01 14:21 ` Johannes Schindelin via GitGitGadget [this message]
2026-09-02  6:25   ` [PATCH 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW Junio C Hamano
2026-09-11 12:25     ` Johannes Schindelin
2026-09-01 14:21 ` [PATCH 2/2] ci(windows): build with Rust Johannes Schindelin via GitGitGadget
2026-09-11 19:08 ` [PATCH v2 0/2] Use Rust in the Windows CI jobs Johannes Schindelin via GitGitGadget
2026-09-11 19:08   ` [PATCH v2 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW Johannes Schindelin via GitGitGadget
2026-09-11 21:09     ` Junio C Hamano
2026-09-11 22:26       ` James Le Cuirot
2026-09-13 10:30         ` Johannes Schindelin
2026-09-11 19:08   ` [PATCH v2 2/2] ci(windows): build with Rust Johannes Schindelin via GitGitGadget
2026-09-13 10:31 ` [PATCH v3 0/2] Use Rust in the Windows CI jobs Johannes Schindelin via GitGitGadget
2026-09-13 10:31   ` [PATCH v3 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW Johannes Schindelin via GitGitGadget
2026-09-13 10:31   ` [PATCH v3 2/2] ci(windows): build with Rust Johannes Schindelin via GitGitGadget
2026-09-13 15:57 ` [PATCH v4 0/2] Use Rust in the Windows CI jobs Johannes Schindelin via GitGitGadget
2026-09-13 15:57   ` [PATCH v4 1/2] rust: pick a GCC-compatible Cargo target under MSYS2/MinGW Johannes Schindelin via GitGitGadget
2026-09-13 15:57   ` [PATCH v4 2/2] ci(windows): build with Rust Johannes Schindelin via GitGitGadget
2026-09-13 22:52   ` [PATCH v4 0/2] Use Rust in the Windows CI jobs Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b7f58a037592325c2cb9b52bf8f1ef434bd6202.1788272509.git.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.