Fix build git installers in v2.53.0 rc1 #852
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The v2.53.0-rc0.vfs.0.0 build began failing with:
Undefined symbols for architecture arm64:
"_iconv", referenced from:
__libintl_find_msg in libintl.a[arm64][13](dcigettext.o)
"_iconv_open", referenced from:
__libintl_find_msg in libintl.a[arm64][13](dcigettext.o)
ld: symbol(s) not found for architecture arm64
See https://github.com/microsoft/git/actions/runs/21450597958 for the
failing run. The previous release v2.52.0.vfs.0.5 built successfully on
January 24, 2026 (https://github.com/microsoft/git/actions/runs/21313971421).
The root cause is upstream commit cee341e ("macOS: use iconv from
Homebrew if needed and present", 2025-12-24), which was included in Git
v2.53.0-rc0 to work around an iconv bug in macOS 15.7.2. That commit
introduced USE_HOMEBREW_LIBICONV, which config.mak.uname now sets on
Darwin 24+, causing the Makefile to add Homebrew's libiconv to the
linker search path.
The problem is a symbol name mismatch: Homebrew's libiconv exports
symbols with a prefix (_libiconv, _libiconv_open) to avoid conflicting
with the system library, but Homebrew's gettext/libintl was built
against the system iconv which uses unprefixed symbols (_iconv,
_iconv_open). When building universal binaries, the linker finds
Homebrew's libiconv first and cannot resolve the symbols libintl needs.
The fix is to explicitly unset USE_HOMEBREW_LIBICONV and ICONVDIR in
config.mak, forcing the linker to use the system's /usr/lib/libiconv.dylib
which is already universal and exports the correct unprefixed symbols.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Starting with upstream commit 4580bcd ("osxkeychain: avoid incorrectly skipping store operation", 2025-11-14), the osxkeychain credential helper includes git-compat-util.h and links against libgit.a. The osxkeychain Makefile has: CFLAGS ?= -g -O2 -Wall -I../../.. $(BASIC_CFLAGS) The ?= operator means "set only if not already set". When building via a parent Makefile that passes CFLAGS on the command line, this entire assignment is ignored - including the -I../../.. needed to find git-compat-util.h and the $(BASIC_CFLAGS) needed for -DNO_OPENSSL: git-credential-osxkeychain.c:5:10: fatal error: 'git-compat-util.h' file not found Using += instead of ?= is not sufficient either, because command-line variables in Make override even += assignments. We need to use "override CFLAGS +=" to force these flags to be appended regardless of how CFLAGS was set. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Starting with upstream commit 4580bcd ("osxkeychain: avoid incorrectly skipping store operation", 2025-11-14), the osxkeychain credential helper includes git-compat-util.h. That header includes openssl/ssl.h unless -DNO_OPENSSL is defined: ../../../git-compat-util.h:199:10: fatal error: 'openssl/ssl.h' file not found On macOS, the main Makefile sets NO_OPENSSL (because Apple Common Crypto is used instead) and adds -DNO_OPENSSL to BASIC_CFLAGS. But contrib Makefiles that only include config.mak* files don't get this logic - they only see the variables, not the Makefile rules that convert NO_OPENSSL into -DNO_OPENSSL. Add -DNO_OPENSSL to BASIC_CFLAGS in config.mak so that contrib builds like osxkeychain can pick it up. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
This is actually `-rc1`, but this file was not adjusted before tagging. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
Author
mjcheetham
approved these changes
Jan 30, 2026
Member
mjcheetham
left a comment
mjcheetham
left a comment
There was a problem hiding this comment.
Thanks for digging into this!
dscho
added a commit
that referenced
this pull request
Jan 31, 2026
This includes the fixes I had to make to get https://github.com/microsoft/git/releases/tag/v2.53.0-rc0.vfs.0.0 to build, plus a fix for an overlooked stale `GIT-VERSION-GEN`,
dscho
added a commit
that referenced
this pull request
Feb 3, 2026
This includes the fixes I had to make to get https://github.com/microsoft/git/releases/tag/v2.53.0-rc0.vfs.0.0 to build, plus a fix for an overlooked stale `GIT-VERSION-GEN`,
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This includes the fixes I had to make to get https://github.com/microsoft/git/releases/tag/v2.53.0-rc0.vfs.0.0 to build, plus a fix for an overlooked stale
GIT-VERSION-GEN,