Cygwin is a free and open-source Unix-like environment and command-line interface for Microsoft Windows. It provides a Linux-like API on Windows such as UNIX sockets, fork(), threads, signals, /proc filesystem, etc. I recently merged multiple changes to fix Cygwin issues and I wrote many changes to fix the Python test suite on Cygwin (issue). If you want to try it, see instructions to build Python on Cygwin.
Python already provides Windows binaries with native Windows support on python.org (PyManager). Supporting Cygwin is mostly useful to users of the Cygwin environment. Cygwin is not Linux and is not Windows, itâs a different platform in-between. Iâm not sure if it would be worth it to go further in terms of support (set up a buildbot, fix the few last tests failing on Cygwin, promote the platform to PEP 11 Tier-3).
I started to work on Cygwin support since I noticed multiple users reporting Cygwin issues and proposing fixes. If there are enough Cygwin users, maybe it would be interesting to go further in terms of support. Well. I donât know, thatâs why Iâm posting my message here The latest packaged Python version in Cygwin is Python 3.12. The package has multiple downstream patches (they should no longer be needed on Python 3.16 with recent Python changes).
I also had a quick look at MinGW. I understood that itâs a toolchain to build Unix applications on Windows targeting the Windows native API. Iâm not sure that itâs useful to support MinGW, since Python already supports the Windows native API (without MinGW). I also quickly gave up because the Python build failed with a lot of compiler errors.
I didnât realize Cygwin was still used significantly, I thought most tools had moved on to mingw (I think git uses or used this at one point?) or the WSL.
One in-between unsupported and making Cygwin tiered would be to add yourself (if you are willing) as a platform expert: Experts index. I think in general it would be good to try to encourage people providing multiple patches for unsupported platforms to be added as experts if they are willing so we have a clearer picture of what platforms are used. I have dreams of adding a âcommunity supported/unofficialâ tier some day so we can enumerate where CPython is run, but that is itâs own discussion.
Last I used it (which was maybe 5 years ago, so could be out of date!) the ABI is different between MSVC and mingw/gcc binaries, so I suppose if someone wanted to embed CPython in a mingw compiled application maybe that would be an issue? But given we havenât seen issues around it, maybe that isnât a current use case.
With mingw-w64, you can target Microsoftâs UCRT (~= C stdlib), which means the ABI is compatible; hereâs a relevant discussion issue that might be of interest. Any remaining ABI differences (up to toolchain bugs) are then confined to C++ code, where GCC and MSVC do not produce compatible things, generally speaking.
For historical interest, the website of the now-defunct mingwpy project contains a lot of interesting (though likely outdated) content about these topics, e.g. details about linking to UCRT.
The only user I still know of for Cygwin is OpenJDK for their releases (and I know at least one person involved with that who would say they wish they didnât use it, but momentum and all).
We actually use Cygwin ourselves to build libffi for use in ctypes. I think it will run with MinGW (it just seems to need Bash for their build scripts), but havenât invested the time to try porting it.
I agree with Victorâs initial post, Cygwin is not Windows and not Unix, which means it has all of its own issues. If people want to contribute fixes (that donât regress other platforms), we should certainly accept them.
Given [my understanding of] how Cygwin operates (more like an integrated Linux distro, everything built together), I think weâd want encouragement/involvement from one of their maintainers to start more formally trying to support it. They may prefer to be fully downstream, rather than having to worry about us chasing their older versions while theyâre looking towards newer versions.
We had a similar situation in PyInstaller a while ago. At least for us, the high bug/PR counts were more a byproduct of how easy it is to break and how easy it usually is to fix (mostly adjusting which branch of an if windows/if unix condtion it should follow) than a high user count. The download counts on PyPI stats were 50/month which is low even compared to platforms Iâd consider esoteric like OpenWRT+MIPS (used by Wi-Fi routers).
We added it to CI anyway. Asides from eating CI time, it hasnât given me any reason to regret adding it.
The MSYS2 project maintains a CPython fork that is buildable with mingw-w64 + gcc/clang. Itâs currently used in MSYS2 and built on Windows, as well as in llvm-mingw where it is cross-compiled on Linux. Not saying that it should be supported, just wanted to share the information in case someone is interested in it.
msys2-runtime which is a friendly fork of cygwin, is still used significantly. There are still some small differences between msys2-runtime and cygwin, but they are mostly the same (see also: How does MSYS2 differ from Cygwin? and Move the build environment closer to Cygwin #3012). In particular, git-for-windows is based on msys2, and people who use git-bash are using msys2-runtime under the hood.
Indeed, and mingw and Cygwin are not the same thing. The former provides a Windows-native GNU build toolchain, but does not make it possible to compile arbitrary POSIX-compatible code on Windows. Cygwin does by providing a (mostly) POSIX-compatible API on top of Windows (as well as a handful of Linux-specific APIs) through its own cygwin.dll runtime library that must be linked to any software compiled for Cygwin. Itâs very much its own platform in a way (the Cygwin runtime also has a few Cygwin-specific APIs of its own). A lot of software intended for unices can be compiled for Cygwin and âjust workâ unmodified. Sometimes a sprinkling of #ifdef __CYGWIN__ need to be patched in here and there. The Cygwin project also maintains its own fairly large package repository.
I admit I donât know how common it is anymore though some examples were cited above, but some software, including untold amounts of commercial software, support Windows via Cygwin. Itâs possible to do this without the user even noticingâyou just have to bundle it with a compatible cygwin1.dll. This was the approach I took some years ago to supporting the installation of SageMath on Windows, which worked remarkably well as Sage has over 100 dependencies though is primarily Python + Cython. Unfortunately I no longer had time to maintain it and no one else stepped up. So Iâm not suggesting that as a reason to formally support Cygwin (though itâs why in the past I tried to work on it).
In any case everyone who does use Cygwin have gotten be pretty well for a long time without it being an âofficiallyâ supported platform by CPython, via patching. Iâm not sure whether or not it has to be officially supportedâbut the willingess of core developers to accept patches targeting Cygwin as long as they are not too disruptive, and Victorâs recent work on getting some of those patches in, is still a help nonetheless and will reduce the maintenance burden for Cygwin packagers wishing to continue supporting Python.
tl;dr I donât know if itâs worth putting a ton of effort into Cygwin, but it shouldnât be dismissed either where small wins can be made to support it.
I started to use Cygwin long (longâŠ) time ago.
It was 1999 if I remember well, MSys2 didnât exist and the best way for building application with free tools for Windows was DJGPP with RSXNTDJ, together with some basic, weak support for some GNU tools like Bash, Bison, etc.
Instead, Cygwin was born from another idea: rather than porting the sources, it allows to compile unmodified source code and run them with a compatibility layer.
In my opinion, Cygwin has several advantages to other solutions like virtual machines or WSL/WSL2 because itâs much more well integrated with Windows.
From my experience, unless something recently changed, WSL is unusable for my needs because it doesnât allow to talk with serial USB devices.
For example, this means that there is no way to use RS232 to USB converters and programmers that I use for talking with embedded devices based on microcontrollers, but this is just an example.
Instead, there are no such limitations on Cygwin, it never needed a CPU with virtual extensions and it inherits advantages and disadvantages of PE executables and DLLs.
Next, WSL requires a distribution to be installed.
This means that you can easily use something between 20GB to 30GB of disk space, when you start to add packages if you want to build something heavy.
Instead, Cygwin eats much less space, with 5GByou you can get a pretty complete environment, although the term âcompleteâ depends on the number of packages that Cygwin can offer.
Unfortunately, here we got the weak point because the trouble is the lack of people for updating obsolete packages or adding new ones.
With the hope to contribute and make something that will be accepted by the Cygwin team in their released packages, I did a tiny repository with some updated libraries for Cygwin, including also some new stuff:
as you can see, there are also several cross compilers for ARM/Aarch64, AVR, DOS/DJGPP, MIPS64, RISCV32 and RISCV64 and some Assemblers for some ancient 8-bit CPUs.
Nowadays, after a number of patches accepted by the author, I have been able to run Codelite IDE on Cygwin, so you can use the various cross compilers in a very simple manner, like you can do on a real UNIX:
Cygwin also provides modern MinGW-w64 cross compilers for x86_64 and i686 but not for Aarch64.
Actually, I also did another repository with Binutils, cross GCC toolchain and packages for Woa64 (Windows on ARM64), but at the moment Iâm maintaining locally and the copy on GitHub is still empty.
My Woa64 tools are based on the work provided by this:
(search âWAE Windows-on-arm-Experimentsâ on GitHub, unfortunately I cannot add more than 2 links for each post)
although Iâm trying to migrate to official GCC-16.1 and Binutils-2.46.
I compiled lot of stuff for Win32/Win64/Woa64, thanks to Cygwin and these cross compilers.
Itâs true that WoA can also run applications for Intel CPUs with a software emulator, but honestly the speed seems the one that you can get with an Atom CPU inside a netbook (no offence, take it just as a personal opinion).
In short, you must compile your application for Woa64 as native Aarch64 code, if you want to get the best experience.
Sometimes it happens that I would like to build some software that exists for Intel CPUs but not for ARM64 but it often happens that something tells me âHey, you must install package âfoobarâ first!â and the build process halts.
Several times, it happened that I could not build some stuff because Python for the MinGW cross compiler was not available.
For example, I was not able to build FreeCAD as a native Woa64 application because of this absence.
I have to say that Python for the x86_64 and i686 ports of MinGW was also missing, so the work for Woa64 will be good also for the toolchains for Win32 and Win64.
So, letâs try to build Python for MinGW, but this first error happened:
checking for git⊠found
checking build system type⊠x86_64-pc-cygwin
checking host system type⊠x86_64-w64-mingw32
configure: error: Cross compiling requires --with-build-python
I added option --with-build-python as requested and this has been printed:
checking for --with-build-python⊠configure: error: â/usr/bin/pythonâ has incompatible version 3.12 (expected: 3.16)
So, I MUST compile Python for Cygwin first.
Rather than trying to fix older versions, why not contributing a working port?
It is a nice challenge, in my opinion.
However, I was pretty confident that much of the work was already done because Cygwin aims to be POSIX.
Hopefully, at least the patches provided by me are very simple changes like testing __CYGWIN__ on existing #ifâŠ#endif blocks.
Perhaps, some of them could be evaluated to be backported into the upcoming 3.15, because they donât seems to me dangerous changes for other platforms.
Thanks to the help of everyone, it seems that support for Cygwin becomes much more solid in the last days.
Now, trying to compile Python for the MinGW cross compilers advanced a step forward:
checking for git⊠found
checking build system type⊠x86_64-pc-cygwin
checking host system type⊠x86_64-w64-mingw32
checking for --with-build-python⊠/home/carlo/packages/python/inst_cygwin/bin/python3.16
checking for Python interpreter freezing⊠/home/carlo/packages/python/inst_cygwin/bin/python3.16
checking for python3.16⊠(cached) /home/carlo/packages/python/inst_cygwin/bin/python3.16
checking Python for regen version⊠Python 3.16.0a0
checking for x86_64-w64-mingw32-pkg-config⊠/usr/bin/x86_64-w64-mingw32-pkg-config
checking pkg-config is at least version 0.9.0⊠yes
checking MACHDEP⊠configure: error: cross build not supported for x86_64-w64-mingw32
Unless people are actively asking for this - and I have no personal insight into how many Cygwin issues are being filed - it doesnât seem worth adding better support for a platform whose popularity is clearly fading. I used Cygwin for a couple of decades to maintain sanity on Windows platforms, Iâm not criticising it at all, but there are now other ways to solve the problems it helped with and itâs clear the level of activity in maintenance and updates is nowhere near what it was in its heyday.
In fact, Cygwin has been supported by Rust as a tier-3 target[2] since Rust 1.86.0[3]. And there are some Rust Cygwin packages provided by MSYS2, including fish v4[4]. CPython has also merged some changes to improve Cygwin support. So I would say Cygwinâs popularity is increasing, not fading.
@carlo-bramini (and other interested people): While the CPython team doesnât support the platform, we can help you support it.
You might want to read the unsupported platforms policy.
If you want to be consulted on Cygwin issues, add yourself to the platform experts list.
Note that issues with the OS-unsupported tag get on a GH project, and (manually, after a delay) tagged with the platform. Not sure if that helps you now, but if the platform ever gets official support weâll re-tag all these as OS-cygwin.
Perhaps, some of them could be evaluated to be backported into the upcoming 3.15
We generally donât do that; if you want to support the platform youâll be much better off maintaining a set of patches which get upstreamed to CPython over time. Thatâs the way Linux distros do it. (You can also do a fork, but individual patches are easier to find, polish and turn into PRs.)
As a CPython maintainer, if I see a #ifdef __CYGWIN__ patch, Iâm much more comfortable merging it if I know it comes from âtheâ CPython for Cygwin project, and is tested & used.
The latest packaged Python version in Cygwin is Python 3.12. The package has multiple downstream patches (they should no longer be needed on Python 3.16 with recent Python changes).
