Build MacVim binary release with GNU iconv instead of Apple iconv #1626
+51
−8
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.
The builtin iconv in macOS has been quite buggy since macOS 14, when Apple replaced GNU iconv with a bespoke version. It introduced backwards-incompatible changes, and behaves oddly in certain character substitutions.
As such, build the official binary release using GNU iconv instead of system iconv. This means we have to compile/cache it manually in our CI just like gettext/libsodium in order to have a universal x86/arm64 binary with the correct deployment target set. We also need to modify gettext to be built against GNU iconv as well to avoid link-time errors.
Note that this does not affect the Homebrew release of MacVim. The standard Homebrew gettext is still linked against system iconv, and as such we can't make an unilateral change without modifying Homebrew's gettext as well.
This will result in the Vim binary being larger by 2 MB. It's not ideal but tolerable. If Apple fixes their implementation of iconv we could revert this in the future.
Related: #1624