change mimalloc_rust build to more strictly follow original mimalloc sources build system#160
Open
Havunen wants to merge 2 commits intopurpleprotocol:masterfrom
Open
Conversation
This was referenced Apr 23, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 PR fixes: #159
Its a workaround to compile the mimalloc using C++ compiler for Windows ARM / MSVC family
Original issue has been raised to mimalloc: microsoft/mimalloc#1277
However, there were some differences in this Rust mimalloc build system compared to mimalloc official sources, this PR addresses those.
tested here: Auto-Explore/GitComet#160
GPT 5.4 Analysis
For the Windows ARM/MSVC-family bug, the highest-priority gap is that git/mimalloc_rust/libmimalloc-sys/build.rs:27 still compiles src/
static.c and only does build.cpp(true) on MSVC-like compilers at git/mimalloc_rust/libmimalloc-sys/build.rs:85. Upstream is stronger: it
forces C++ on MSVC/clang-cl and treats src/static.c as C++ source in CMakeLists.txt:177 and CMakeLists.txt:577. I would add c++17, /Zc:__cplusplus, and
either /TP or a .cc wrapper around static.c.
For release parity, build.rs only sets MI_DEBUG=0 in non-debug builds at git/mimalloc_rust/libmimalloc-sys/build.rs:75. Upstream also adds
MI_BUILD_RELEASE in release-like configs at CMakeLists.txt:612. That matters because the vendored source checks MI_BUILD_RELEASE/NDEBUG separately in /
home/sampo/git/mimalloc_rust/libmimalloc-sys/c_src/mimalloc/v3/include/mimalloc/types.h:73 and git/mimalloc_rust/libmimalloc-sys/c_src/
mimalloc/v3/src/os.c:140. I would define MI_BUILD_RELEASE and NDEBUG in non-debug Cargo profiles.
For arm64 performance, the Rust wrapper has no equivalent to upstream MI_OPT_ARCH. Upstream auto-enables that on arm64 in CMakeLists.txt:162 and uses
-march=armv8.1-a or /arch:armv8.1 in CMakeLists.txt:505. That is the main missing perf flag.
Optional but useful: expose MI_WIN_DIRECT_TLS=1 as an opt-in Windows feature from CMakeLists.txt:422, and add -fno-builtin-malloc when the Rust override
feature is used, to match CMakeLists.txt:488