Add Mingw build to meson-ci #41244
Add Mingw build to meson-ci #41244
Conversation
Fix for
src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:
2025-11-29T22:55:09.9262575Z In function
2025-11-29T22:55:09.9262723Z '__pyx_gb_4sage_6graphs_4base_18static_dense_graph_13generator1':
2025-11-29T22:55:09.9263047Z src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:19862:88:
2025-11-29T22:55:09.9263213Z error: passing argument 1 of '_bitset_len' from incompatible pointer
2025-11-29T22:55:09.9263401Z type [-Wincompatible-pointer-types]
2025-11-29T22:55:09.9263473Z 19862 | __pyx_t_9 =
2025-11-29T22:55:09.9263601Z PyInt_FromSsize_t((__pyx_cur_scope->__pyx_v_num_edges
2025-11-29T22:55:09.9263701Z + _bitset_len((&__pyx_cur_scope->__pyx_v_c), 1))); if
2025-11-29T22:55:09.9263813Z (unlikely(!__pyx_t_9)) __PYX_ERR(0, 688, __pyx_L1_error)
2025-11-29T22:55:09.9263872Z |
2025-11-29T22:55:09.9263941Z ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-11-29T22:55:09.9263992Z |
2025-11-29T22:55:09.9264050Z |
2025-11-29T22:55:09.9264101Z |
2025-11-29T22:55:09.9264192Z mp_bitcnt_t * {aka long unsigned int *}
2025-11-29T22:55:09.9264262Z In file included from
2025-11-29T22:55:09.9264587Z src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:1228:
2025-11-29T22:55:09.9264748Z ..\src\sage\data_structures/bitset_intrinsics.h:272:43: note: expected
2025-11-29T22:55:09.9264889Z 'mp_limb_t *' {aka 'long long unsigned int *'} but argument is of type
2025-11-29T22:55:09.9264978Z 'mp_bitcnt_t *' {aka 'long unsigned int *'}
2025-11-29T22:55:09.9265124Z 272 | static inline long _bitset_len(mp_limb_t* bits, mp_bitcnt_t
2025-11-29T22:55:09.9265178Z limbs){
2025-11-29T22:55:09.9265261Z | ~~~~~~~~~~~^~~~
2025-11-29T22:55:09.9265560Z src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:
2025-11-29T22:55:09.9265649Z In function '__Pyx_ImportType_3_0_12':
2025-11-29T22:55:09.9265978Z src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:28401:13:
2025-11-29T22:55:09.9266139Z warning: unknown conversion type character 'z' in format [-Wformat=]
2025-11-29T22:55:09.9266246Z 28401 | "%s.%s size changed, may indicate binary
2025-11-29T22:55:09.9266322Z incompatibility. "
2025-11-29T22:55:09.9266375Z |
2025-11-29T22:55:09.9266467Z ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-11-29T22:55:09.9266793Z src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:28402:24:
2025-11-29T22:55:09.9266871Z note: format string is defined here
2025-11-29T22:55:09.9267004Z 28402 | "Expected %zd from C header, got %zd from PyObject",
2025-11-29T22:55:09.9267151Z | ^
2025-11-29T22:55:09.9267469Z src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:28401:13:
2025-11-29T22:55:09.9267629Z warning: unknown conversion type character 'z' in format [-Wformat=]
2025-11-29T22:55:09.9267730Z 28401 | "%s.%s size changed, may indicate binary
2025-11-29T22:55:09.9267803Z incompatibility. "
2025-11-29T22:55:09.9267855Z |
2025-11-29T22:55:09.9267938Z ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-11-29T22:55:09.9268266Z src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:28402:47:
2025-11-29T22:55:09.9268344Z note: format string is defined here
2025-11-29T22:55:09.9268464Z 28402 | "Expected %zd from C header, got %zd from PyObject",
2025-11-29T22:55:09.9268549Z | ^
2025-11-29T22:55:09.9268861Z src/sage/graphs/base/static_dense_graph.cp313-win_amd64.pyd.p/src/sage/graphs/base/static_dense_graph.pyx.c:28401:13:
2025-11-29T22:55:09.9269001Z warning: too many arguments for format [-Wformat-extra-args]
2025-11-29T22:55:09.9269096Z 28401 | "%s.%s size changed, may indicate binary
2025-11-29T22:55:09.9269161Z incompatibility. "
2025-11-29T22:55:09.9269215Z |
2025-11-29T22:55:09.9269366Z ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's not part of the C standard, and not provided on Windows. Fix for src/sage/plot/plot3d/shapes.cp311-win_amd64.pyd.p/src/sage/plot/plot3d/shapes.pyx.c:12624:35: error: 'M_PI' undeclared (first use in this function) 12624 | __pyx_t_3 = PyLong_FromDouble(((M_PI * __pyx_v_self->radius) / __pyx_v_ds)); if (unlikely(!__pyx_t_3)) __PYX_ERR(0, 959, __pyx_L1_error)
Fix for [1/775] Linking target src/sage/rings/real_mpfi.cp311-win_amd64.pyd FAILED: [code=1] src/sage/rings/real_mpfi.cp311-win_amd64.pyd "cc" -o src/sage/rings/real_mpfi.cp311-win_amd64.pyd src/sage/rings/real_mpfi.cp311-win_amd64.pyd.p/meson-generated_src_sage_rings_real_mpfi.pyx.c.obj "-Wl,--allow-shlib-undefined" "-Wl,-O1" "-shared" "-Wl,--start-group" "-Wl,--out-implib=src\sage\rings\real_mpfi.cp311-win_amd64.dll.a" "C:\Users\Tobia\AppData\Local\Programs\Python\Python311\python311.dll" "C:/rtools45/ucrt64/lib/libgmp.dll.a" "-lmpfi" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32" "-Wl,--end-group" C:/rtools45/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src/sage/rings/real_mpfi.cp311-win_amd64.pyd.p/meson-generated_src_sage_rings_real_mpfi.pyx.c.obj:real_mpfi.pyx.:(.text+0x471b): undefined reference to `mpfr_equal_p
Good to see that people are noticing that, and it's also good to see that this opens up more options. :)
I already gave the latest release of ecl a shot a few months ago, and I did not succeed to package that. If I remember correctly, most of the issues were due to the fact that the ecl codebase wasn't ready for GCC 15 and the C23 standard it uses by default. I may try again in a while or when a new release comes out. Or just try with C17 instead and see how far that gets me. Maxima depends on ecl (or at least a Common Lisp environment), so those both kind of go hand in hand. There currently is a package for Steel Bank Common Lisp in MSYS2, but only for a few environments (no Clang, no ARM64), so we could get Maxima but not ecl. Not sure whether this is viable for Sage.
According to their documentation it should be possible to build Singular for MSYS2 / MINGW-64, although it will probably start with fewer features than on Linux. Haven't tried it yet, but it's on my list. I did not have the time to look into most of the other dependencies yet, but I expect packages like libcliquer, libplanarity, rw and m4rie to be doable in MSYS2 / MINGW64, too. So some of that stuff may (or may not) be coming in the next few weeks. |
Fix for
SAGE_NAUTY_BINS_PREFIX = "D:\a\_temp\msys64\ucrt64\bin\.EXE"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 17-19: truncated \uXXXX escape
Yes, thanks a lot! If you have the time, it would be awesome if you could also package sage itself (perhaps after the next (beta) release containing the fixes in this PR here).
I know that one can build ecl even with MSVC, and MinGW should be easier in principle. So I would hope that apart from the c-standard issues you wouldn't face big obstacles.
We need a maxima that is compiled with ecl.
No hurry, those are not very urgent. Most of them are only used in small parts of sage, or are completely optional and would enable some (smaller) features. See also #40676 for an overview of the state of dependencies on Windows. The biggest missing deps are really gap + maxima, and without them sage is a bit like a car with only three wheels: may look nice but doesn't really drive well. |
to make it easier to specify the absolute path of the nauty exe
|
The test failures seem to be unrelated. |
I'm not sure that MSYS2 has all the packages required to do that, yet.
I gave it another shot. ecl basically builds when using a newer Git checkout instead of the latest release from more than a year ago. The C23 stuff sems to be fixed in Git, but not on the release. But after the build somehow paths seem to be messed up, with files landing in places where they should not be, despite giving the prefix path to the configure script. That way it's not really useful and other programs (like Sage) may have trouble with it. But yeah, ecl seems to build in general.
Thanks for the clarification.
I haven't checked gap itself yet, but if I remember correctly, then some of its dependencies (or dependencies of its dependencies) did not build. Maybe they are optional or one can work around this, since gap seems to provide a Windows binary (https://www.gap-system.org/install/windows/). |
|
GAP Windows binary uses Cygwin, with cygwin DLL bundled. Besides, we need libgap, a DLL, to build a GAP interface |
It should work. If an dependency is not available, we simply don't try to compile the extension modules that are depending on it. This is also what is tested with the CI added in this PR here: install all msys dependencies, and then simply build sagemath using
Thanks for trying again. Perhaps the build scripts for conda might help solving the prefix issue? You can find them at:
I started working on MinGW support for gap in gap-system/gap#6077. |
3 participants
Thanks to the recent iniative of @striezel more dependencies of Sage are now available on MinGW. So it makes sense/it is possible to build Sage in MinGW now (in addition to the conda-on-windows build env).
A few issues had to be fixed to have it compile successful, see commit messages for details.
There are still quite a few ('optional') dependencies missing (the first 4 are probably the most important ones - as they would unlock a truly useful version of Sage on Windows):
📝 Checklist
⌛ Dependencies