Add initial support for building with mingw #35796
Conversation
|
Added a GH Actions workflow (WIP) because I don't have a way to test this locally |
|
The MSYS2 that is installed on the GH Actions runners reports itself as |
|
Documentation preview for this PR (built with commit c50d285) is ready! 🎉 |
Allowing the mingw32 target triples is necessary for building sage using mingw, so add it to the list of supported triples in configure.ac.
MSYS's default behavior when trying to create a symlink is to copy the source file/folder to the destination since there's no reliable way to create a symlink visible to Windows-native (non-cygwin) programs. The configure script tries to symlink lib64 to lib, which fails with that default behavior, so change the settings so MSYS generates Cygwin-only symlinks so that we can make lib64 be a symlink. It remains to be seen whether enabling symlinks will cause problems at a later point due to the fact that they won't be symlinks on Windows.
When building a small C extension to check if distutils is correctly installed, change the extension name in the setup Python script to match the name for the module specified in the C/C++ file. Python on Linux doesn't seem to have a problem with those 2 names being different, but having different names there on Windows results in an error, so fix that by just using the same name in both places.
As explained in the added comment, the default Python that MSYS puts on PATH is a Windows-based Python that is expecting Windows file paths, not cygwin/MSYS file paths, so using that Python for bootstrapping will break the build system.
Remove crypt from the list of modules that we try to import when checking whether a given system python will work for our purposes, since: - It doesn't work on Windows (so it prevents us from running sagemath on Windows) - Searching the entire repo doesn't find any uses of crypt - crypt is deprecated anyways (PEP 594 has its removal scheduled for Python 3.13) The check for crypt was added at the same time as the other modules being checked, but neither the commit message for 6fcd7cd nor the discussion in Trac sagemath#27824 mentions why crypt specifically was added (Most of the relevant discussion in that ticket is about the distutils check).
As mentioned in the added comment, the code for tuning gf2x fails on Windows, so avoid running that tuning code.
See reasoning for patching cliquer at the top of the patch file.
ncurses on MSYS seems to have an ncursesw.pc file but no ncurses.pc file, so update the ncurses spkg to search for that too when looking for suitable system packages.
As mentioned in the added comment, failing to do this causes the NTL build to fail on MSYS.
Instead of using MSYS's default of copying files to the destination when asked to create a symlink, enable symlinks globally for the entire `make` run in the hopes that packages relying on symlinks to build are more likely to succeed.
As mentioned in the added comment, enabling symlinks on MSYS causes the build to fail (since the mingw gcc doesn't understand MSYS symlinks), so disable them for the gf2x (since the MSYS-default behavior of copying works).
Partially reverts commit b3a6260323668333df32f54d9bccbd32e5d99898. As it turns out, defining `_MSC_VER` through CFLAGS causes compilation errors where the linker starts complaining about redefinition of many different standard library symbols. Revert that part for now, since the better fix is probably extending the existing msvc detection to work on mingw as well.
As mentioned in the comment, MSYS changing the default OS separator for the Windows Python breaks setuptools attempts to install itself, so this fixes that. Long term, the right fix for this is probably replacing the currently deprecated `setup.py install` command with `pip install` in some form, since the bug seems to occur in setuptools' installation logic (and using `pip install` would probably use pip for that installation logic, instead of setuptools). That being said, this is a really hacky but technically functional fix that seems to work for now.
Don't list crypt as a part of the list of necessary modules for Python, since we no longer check for crypt.
Detect if we're running on msys, and, if so, suggest msys packages to install with the package manager instead of Arch packages, since the latter don't necessarily correspond to valid packages on msys.
Add names of MSYS system packages for various different SPKGs to make it easier to find packages to install on MSYS. `_bootstrap` and `_prereq` files are copied from their equivalents for Arch, and the rest are generated through a combination of repology, checking the output of `pacman`, and manual checking.
|
I am not sure if this matters for you, but Singular and GAP won't build under MingW. For GAP, see gap-system/gap#4157 for a rough overview of what would need to be done to change that. |
|
A good strategy for porting could be to first get the modularized distribution packages running |
I don't think so. That sounds like it's using the MSYS environment (which is essentially just cygwin) instead of the MINGW64 environment (see here for more info on MSYS2 environments). I think what we're looking for corresponds to setting |
|
@pranavrajpal are you still interested in Windows support for sage? Then you might have a look at #38872, which compiles sage natively on windows (using meson). So far I've only tested it with MSVC, perhaps a bit more fine tuning is necessary for mingw. |
📚 Description
This adds some initial support for using MSYS2 to build a mingw-based version of sagemath (which would allow sagemath to run on Windows without needing cygwin or WSL). This PR is mostly just various changes to fix compilation/build errors (more details about the specifics of each change in the commit messages/comments), as well as support for displaying which MSYS2 system packages correspond to some SPKGs.
Current status of this:
./configureneeds to have"--prefix=$(pwd -P)/local"explicitly passed in since MSYS overrides the prefix to be/mingw64(see here) which leads to sagemath being installed in the wrong place if you use just./configureEven with those limitations, I still think this is a worthwhile change since it brings Sagemath closer to a native mingw build.
Works on #31090
📝 Checklist