The macOS build issue seems unrelated to this change, and I'm not sure what's causing it. Interesting that we run into an ASan issue on Ubuntu with the new mimalloc version. I'll try to debug it and report back.

This is an upstream regression (mimalloc#1124), so I'm downgrading mimalloc to v2.2.3 in order to avoid it. I'll open a separate PR to fix two minor test issues that I found while investigating this.

The macOS issue indeed isn't related to this change (encountered 4 months ago by this HN commenter: https://news.ycombinator.com/item?id=43552607), but I have no idea what's causing it and how to fix it becuase I don't have access to a macOS setup.

Based on this CMake issue, I temporarily pushed a commit with the diff below, and it seems to work, so I opened #1614 to fix that, as it's not related to the changes in this PR. I'll rebase this and the other PRs on it after it's merged.

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -136,7 +136,7 @@ if(ENABLE_OPENMP)
     find_package( OpenMP REQUIRED )
     if(OPENMP_FOUND)
         add_library(slvs_openmp INTERFACE)
-        target_compile_options(slvs_openmp INTERFACE ${OpenMP_CXX_FLAGS})
+        target_compile_options(slvs_openmp INTERFACE "SHELL:${OpenMP_CXX_FLAGS}")
         target_link_libraries(slvs_openmp INTERFACE
             ${OpenMP_CXX_LIBRARIES})
         target_include_directories(slvs_openmp SYSTEM INTERFACE

@iscgar Merged 0bf9cbb b9a9e26 592edbd

Offff mimalloc is a PITA, always has been, now the Emscripten builds fail :-(
https://github.com/solvespace/solvespace/actions/runs/16865637438/job/47772106561#step:4:155
https://github.com/solvespace/solvespace/actions/runs/16865637439/job/47772225844#step:4:618

As does all the Python stuff:
https://github.com/solvespace/solvespace/actions/runs/16865637440

@vespakoen can you take a look?

wasm-ld: error: ../bin/solvespace.wasm.lto.libmimalloc.a(os.c.o at 177796).o: undefined symbol: emmalloc_free
wasm-ld: error: ../bin/solvespace.wasm.lto.libmimalloc.a(os.c.o at 177796).o: undefined symbol: emmalloc_free
wasm-ld: error: ../bin/solvespace.wasm.lto.libmimalloc.a(os.c.o at 177796).o: undefined symbol: emmalloc_free
wasm-ld: error: ../bin/solvespace.wasm.lto.libmimalloc.a(os.c.o at 177796).o: undefined symbol: emmalloc_memalign
wasm-ld: error: ../bin/solvespace.wasm.lto.libmimalloc.a(os.c.o at 177796).o: undefined symbol: emmalloc_memalign
wasm-ld: error: ../bin/solvespace.wasm.lto.libmimalloc.a(os.c.o at 177796).o: undefined symbol: emmalloc_free
wasm-ld: error: ../bin/solvespace.wasm.lto.libmimalloc.a(os.c.o at 177796).o: undefined symbol: emmalloc_memalign
wasm-ld: error: ../bin/solvespace.wasm.lto.libmimalloc.a(os.c.o at 177796).o: undefined symbol: emmalloc_memalign

The Python issue is an upstream mimalloc issue, which was fixed in 2.2.4, that we cannot use due to the issue mentioned above. I'll try to find a version that works later today, and report back if I find a good solution that doesn't require reverting the update altogether.

The WASM issue seems to be caused by Emscripten support in mimalloc, which layers it on top of emmalloc (see emscripten-core/emscripten#20651). Choosing to specify -sMALLOC=emmalloc would slow down allocations of everything that doesn't use the temporary heap, so I'm not sure it's the right choice. An alternative might be to just not build mimalloc with Emscripten, and instead specify -sMALLOC=mimalloc, so that the Emscripten mimalloc is used for regular allocations as well.

#1616 should take care of both issues.

Thanks @iscgar for looking at this so quickly and finding a workaround!