Native Windows build #38872
Native Windows build #38872
Conversation
|
Documentation preview for this PR (built with commit 0c51e81; changes) is ready! 🎉 |
../src/sage/symbolic/ginac/upoly-ginac.cpp(219): error C2440: '<function-style-cast>': cannot convert from 'size_t' to 'GiNaC::numeric' ../src/sage/symbolic/ginac/upoly-ginac.cpp(219): note: 'GiNaC::numeric::numeric': ambiguous call to overloaded function
../src/sage/symbolic/ginac/archive.cpp(584): error C2039: 'mem_fun_ref': is not a member of 'std' C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\include\sstream(19): note: see declaration of 'std' ../src/sage/symbolic/ginac/archive.cpp(584): error C3861: 'mem_fun_ref': identifier not found ../src/sage/symbolic/ginac/archive.cpp(584): error C2672: 'for_each': no matching overloaded function found
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\include\xkeycheck.h(341): warning C4005: 'register': macro redefinition ../src/sage/symbolic/ginac/constant.cpp(23): note: see previous definition of 'register' C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\include\xkeycheck.h(343): fatal error C1189: #error: The C++ Standard Library forbids macroizing the keyword "register". Enable warning C4005 to find the forbidden define.
ginac_lst.cpp.obj : error LNK2005: "protected: static void const * __cdecl GiNaC::container<class std::list>::get_tinfo(void)" (?get_tinfo@?$container@Vlist@std@@@ginac@@KAPEBXXZ) already defined in meson-generated_src_sage_symbolic_expression.pyx.cpp.obj
Some of them should perhaps be reverted
`os.uname` is not available on Windows
|
you should merge/rebase over, whatever you prefer, the latest development branch |
I did this yesterday. |
|
The relevant CI tests are green again. |
|
@ptrrsn - this is the Windows build I mentioned. @tobiasdiez can point you at related issues and PRs - this is not what I myself am familiar with. |
CITATION.cff
Outdated
There was a problem hiding this comment.
Something is fishy with your rebase here
The versions should not go backwards
|
By the way, I created a PR for a native Windows build for m4ri (as can be found above), and some PRs to help build GAP on MinGW. |
|
@ptrrsn - please Cc me on these PRs. Sorry for a strange turn of the interaction on the GAP's PR - it's not the first time there. |
|
@dimpase - Thank you for your comments! I just cc'd you on the PRs (including the closed ones). The m4ri one is pretty much done. I will continue working on the GAP native Windows build and probably one or some of the other dependencies mentioned here that do not have a native Windows build yet. |
|
@ptrrsn This is awesome! Thanks for your effort! Once a package builds nicely on Windows, please ping me (either here on in the relevant PR) and I'll help to publish the Windows-version as conda packages. |
|
@tobiasdiez m4ri now supports MinGW on the master branch. |
|
Awesome! |
|
I also added a PR to update MinGW build instructions and added a MinGW CI to m4rie. Aside from GAP (which I am still working on, and an active PR is being reviewed), do we have anything else here that I can help with? |
|
For m4rie, you can already build the Windows version after m4ri works just by following the instructions in that PR above (or following the CI yml file). |
|
@ptrrsn In principle, all dependencies/packages that are currently excluded on windows (https://github.com/search?q=repo%3Asagemath%2Fsage%20is_windows&type=code) needs work. Some of them actually compile fine on Windows, but are not yet available on conda-forge. The 'biggest' ones are probably gap, cypari2, singular and maxima (conda-forge/maxima-feedstock#38). |
|
Thank you. By the way, m4rie PR was also merged (it can build cleaner now on MinGW). |
|
cypari2 might benefit from a general update, as it has a somewhat broken memory design, leading to memory leaks. regarding maxima - I thought ecl does work on Windows. Singular has a rather complicated dynamic libraries setup, building internal dynamic libraries, other than that it's C++. |
|
@dimpase Do you mind to give me the related issues or PRs on the cypari2 memory problems? Maybe I can help with the memory redesign. |
The goal of this PR is to provide a native Windows build of Sage using MSVC (using the new Meson build system).
Instructions on how to test are under the
Windowstab at https://doc-pr-38872--sagemath.netlify.app/html/en/installation/meson.Afterwards, you should be able to import some sage modules in a normal
pythoninstall (but most modules actually don't properly import due to various errors that will be fixed peu a peu in follow-up PRs)State of Windows support of dependencies
Conda Issues:
set LIBincludes the conda env (e.g....\.conda\envs\sage-dev\Library\lib). If not, runconda deactivatefollowed byconda activate sage-devand then check again.set LIB=%CONDA_PREFIX%\Library\lib;%LIB%LIBmeson setup builddir -Dbuildtype=release<path to conda>\sage-dev\include\pyconfig.huncomment://# define Py_DEBUGand changepython311_d.libtopython311.libpyconfig.hgsl.pcto match:c-compileron Windows, VS 2022 Build Tools init file is not installed conda-forge/compilers-feedstock#66LNK2019: unresolved external symbolon Windows conda-forge/m4ri-feedstock#15Upstream issues
Singular
Flint:
smallmacro fromrpcndrflintlib/flint#2100pid_tmingw-w64/mingw-w64#65 (indirectly since pthread is flint dependency). Would be fixed by winpthreads-related issue when compiling against flint conda-forge/libflint-feedstock#38.-> Workaround: Change
typedef __int64 pid_t;totypedef int pid_t;in.conda\envs\sage-dev\Library\include\pthread_compat.h-> Workaround: disable compilation of fraction_field_FpT for now
Cysignals:
📝 Checklist
⌛ Dependencies