Can we build any latest python version on cygwin using the source? Does it require some level of porting or is it supported by default from the open source?
Looks like cygwin stopped updating python a long tine a go.
Can you use WSL (windows subsystem for linux)as a replacement for cygwin?
Thank you, Barry, the thing is I am cross compiling. Cross compilation from windows to Nonstop platform. WSL is out of picture as my cross compilers are windows based if I understand it correctly. Cross compiling any python say Python-3.13 would require build platform to support the same, in my case cygwin which seems to be stuck at 3.9 and I need 3.13 in cygwin.
Is there any way to alleviate the dependency of requiring same major python version required for cross compilation? This is not seen when normally building from source due to bootstrap python right?
Can we build Python for cygwin from source without any issues? Although there is no official support of python for cygwin, basic core functionalities should work right?
I guess you just have to try doing tne build.
I tried it, was able to build with minimal changes, however it doesn’t load modules from lib-dynload like _posixsubprocess, tried setting path variable but it doesn’t seem to work. Then found a thread to correct the same,
Problem with _socket und pyexpat on Cygwin - Python Help - Discussions on Python.org
Basically,
>>> import importlib.machinery
>>> print(importlib.machinery.EXTENSION_SUFFIXES)
['.dll']
>>> import sysconfig
>>> sysconfig.get_config_var("SOABI")
'cpython-311'
importlib.machinery.EXTENSION_SUFFIXES is not correct and needs manual renaming of lib-dynload dlls. If this can be done in automated way during build itself please let me know.
Well done. Is there a hard requirement for Cygwin? I have a lot more luck in general with MSYS2. In that, I used pacman to install Ansible (which needs some kind of posix compatibility layer on Windows) which happened to pull in a Python 3.12 build.
It’s possible to run an MSYS2 app from a normal (cmd) windows terminal, with a small incantation:
C:\Users\...>C:\msys64\msys2_shell.cmd -msys -defterm -no-start -here -c python
Python 3.12.12 (main, Nov 23 2025, 14:30:39) [GCC 15.2.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Quote the Python command to run scripts:
C:\Users\drjam>C:\msys64\msys2_shell.cmd -defterm -no-start -c "python --version"
Python 3.12.12
Python 3.12.12
MSYS2 is based on Cygwin
Since you (Mohammed Zuhaib) mentioned my post from October last year (2025), I finally uploaded the summary of all my efforts getting CPython compiled on Cygwin from that time:
It does not solve all the problems, but strives to be helpful for a successful compilation.
3 Likes
Msys supports 3.12.12 I think and there is no support for 3.13 still in msys shell of msys2, my requirements are for building Python-3.13.
This should be helpful, thank you. But every new release of python will require such patches I believe.
Is the tool chain for that 3.12.12 build really so different for 3.13?
While cross compiling Python of a specific version say 3.13.x the host platform python should be of 3.13.x, this is done to alleviate bootstrap python requirement for cross compiling.
Yes thankyou - I know that very well. My point is, surely it’s a lot easier to work out how to compile 3.13, starting from a known build chain that successfully compiles 3.12.
In any case I’ve not tried this specific version, but there is already a build of 3.13 available:
1 Like
Oh ok, I understand now. Thank you @JamesParrott.
1 Like
I feel that there has to be some RFE to avoid this bootstrap problem while cross compiling python. I was looking at cross compilation of LLVM build, there they build the native components required for host first and using those build the rest of the components. The same can be extrapolated to python, Cpython can build the host(native) bootstrap python first and using that achieve the cross build.
If you figure out how, it could be useful for Python devs targeting iOS too:
A complete build for Python on iOS requires compiling CPython four times: once for macOS; then once for each of the three underlying platforms used by iOS:
- An ARM64 device (an iPhone or iPad);
- An ARM64 simulator running on a recent macOS machine; and
- An x86_64 simulator running on older macOS machine.
The macOS build is required because building Python involves running some Python code.
Is the base Python needed to do more than find system libraries for the target? It’s not unheard of, for CMake to pull in Python, when building C++ apps.
I can work on this in my free time. If the CPython dev agree for an RFE then we can work on this full time.
I think base Python is also needed to set some configurations that make up the sysconfig of the target Python. While using windows python to cross compile for a platform similar to linux, I saw issues popping up in the sysconfig settings of the built python.
I’m guessing it’s hard to justify everyone’s time, simply to avoid boot strapping from a base Python build when cross compiling, when there already are working build processes.
Won’t it require replacing whatever the base Python does at the moment, with shell files, Make files or .bat files etc. that do exactly the same thing?
Once we build host python(minimalist build of what is needed), the same can be used to carry out the rest of the build like normal cross build.
Yes, like you said, simply to avoid bootstrapping it’s difficult to justify this RFE. If we need a host python build we can manually carry out the build from source and use it for cross compiling. The RFE would only automate this step while cross compilation.
1 Like