# Enhance Cygwin support **URL:** \ **Category:** Core Development\ **Created:** [May 26, 2026, 8:44pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537 "2026-05-26T20:44:52Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [May 26, 2026, 8:44pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/1 "2026-05-26T20:44:52Z")
Hi, [Cygwin](https://www.cygwin.com/) 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](https://github.com/python/cpython/issues/149879)). If you want to try it, see [instructions to build Python on Cygwin](https://github.com/python/cpython/issues/149879#issue-4454162707). Python already provides Windows binaries with native Windows support on [python.org](http://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. Victor ---
**Author:** ![emmatyping](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/emmatyping/32/36516_2.png) [@emmatyping](https://discuss.python.org/u/emmatyping)\ **Post date:** [May 26, 2026, 10:01pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/2 "2026-05-26T22:01:58Z")
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](https://devguide.python.org/core-team/experts/#platforms). 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. > [@vstinner](#): > > I’m not sure that it’s useful to support MinGW, since Python already supports the Windows native API (without MinGW). 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. ---
**Author:** ![h-vetinari](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/h-vetinari/32/1220_2.png) [@h-vetinari](https://discuss.python.org/u/h-vetinari)\ **Post date:** [May 26, 2026, 10:37pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/3 "2026-05-26T22:37:14Z")
> [@emmatyping](#): > > 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 With [mingw-w64](https://www.mingw-w64.org/), you can target Microsoft’s UCRT (~= C stdlib), which means the ABI is compatible; here’s a relevant discussion [issue](https://github.com/msys2/MINGW-packages/issues/6901) 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](https://mingwpy.github.io) 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](https://mingwpy.github.io/ucrt.html). ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [May 26, 2026, 10:55pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/4 "2026-05-26T22:55:13Z")
> [@emmatyping](#): > > I thought most tools had moved on to mingw (I think git uses or used this at one point?) or the WSL. 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). ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [May 26, 2026, 11:11pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/5 "2026-05-26T23:11:07Z")
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. ---
**Author:** ![bwoodsend](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bwoodsend/32/4027_2.png) [@bwoodsend](https://discuss.python.org/u/bwoodsend)\ **Post date:** [May 26, 2026, 11:49pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/6 "2026-05-26T23:49:41Z")
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. ---
**Author:** ![lazka](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/lazka/32/35792_2.png) [@lazka](https://discuss.python.org/u/lazka)\ **Post date:** [May 27, 2026, 4:16am UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/7 "2026-05-27T04:16:39Z")
> [@vstinner](#): > > 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. The [MSYS2 project](https://www.msys2.org/) maintains a [CPython fork](https://github.com/msys2-contrib/cpython-mingw) that is buildable with mingw-w64 + gcc/clang. It’s currently used in MSYS2 and built on Windows, as well as in [llvm-mingw](https://github.com/mstorsjo/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. ---
**Author:** ![GalaxySnail](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/galaxysnail/32/5655_2.png) [@GalaxySnail](https://discuss.python.org/u/GalaxySnail)\ **Post date:** [May 27, 2026, 7:16am UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/8 "2026-05-27T07:16:20Z")
> [@emmatyping](#): > > 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. [msys2-runtime](https://github.com/msys2/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?](https://www.msys2.org/wiki/How-does-MSYS2-differ-from-Cygwin/#runtime) and [Move the build environment closer to Cygwin #3012](https://github.com/msys2/MSYS2-packages/issues/3012)). In particular, git-for-windows is based on msys2, and people who use git-bash are using msys2-runtime under the hood. MSYS2 also packages [CPython 3.12 built with msys2-runtime](https://packages.msys2.org/packages/python) with [some patches](https://github.com/msys2/MSYS2-packages/tree/master/python), which differs from the variant built with mingw-w64 (see also [https://www.msys2.org/docs/environments/](https://www.msys2.org/docs/environments/)). ---
**Author:** ![embray](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/embray/32/622_2.png) [@embray](https://discuss.python.org/u/embray)\ **Post date:** [May 27, 2026, 9:45am UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/9 "2026-05-27T09:45:52Z")
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](https://github.com/sagemath/sage-windows-cygwin) 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. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [May 27, 2026, 4:55pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/10 "2026-05-27T16:55:51Z")
I just found out that Cygwin doesn’t Windows ARM64. I also found out that OpenJDK moved to MSYS2. ---
**Author:** ![carlo-bramini](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/carlo-bramini/32/35908_2.png) [@carlo-bramini](https://discuss.python.org/u/carlo-bramini)\ **Post date:** [June 2, 2026, 10:12pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/11 "2026-06-02T22:12:00Z")
Hello, 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: > **[GitHub - carlo-bramini/packages-cygwin: Repository of packages for CYGWIN](https://github.com/carlo-bramini/packages-cygwin)** > > Repository of packages for CYGWIN 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: > > > This PR fixes the last bits for building and installing Codelite for CYGWIN. > Th…is commit to wxdap is also important: > https://github.com/eranif/wxdap/pull/18 > and the link to the submodule needs to be updated for including it in the future. > > Compiling Codelite for CYGWIN is very similar to the guidelines for linux. > After installing needed development libraries, the build tools and the X server with setup utility, you can clone the sources: > \`\`\` > git clone https://github.com/eranif/codelite.git > cd codelite > git submodule update --init --recursive > \`\`\` > Next, you can perform the build with these commands > \`\`\` > mkdir build-release > cd build-release > cmake .. -DCMAKE\_BUILD\_TYPE=Release -G Ninja -DCMAKE\_INSTALL\_PREFIX=${HOME)/inst\_codelite\_wx32 -DCMAKE\_C\_FLAGS="-D\_GNU\_SOURCE" -DCMAKE\_CXX\_FLAGS="-D\_GNU\_SOURCE" -DCMAKE\_SHARED\_LINKER\_FLAGS="-Wl,--export-all-symbols" > ninja > \`\`\` > Here, I used ninja but you can also use the traditional GNU make tool, if you want. > Finally, when the build process completes, you can install the binaries with: > \`\`\` > ninja install > \`\`\` > Now that you installed Codelite, you can run the X server with the following commands: > \`\`\` > export DISPLAY=:0.0 > XWin -multiwindow & > \`\`\` > and run Codelite: > \`\`\` > cd ${HOME)/inst\_codelite\_wx32/bin > ./codelite > \`\`\` > and after few seconds the IDE will appear on your screen: > > \codelite > > Thank you very much for making this possible. > Sincerely, > > Carlo Bramini. 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: ```python 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: ```python 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: ```python 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 ``` But this will be another challenge, my friends. ---
**Author:** ![Jos\_Verlinde](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jos_verlinde/32/25571_2.png) [@Jos\_Verlinde](https://discuss.python.org/u/Jos_Verlinde)\ **Post date:** [June 2, 2026, 11:32pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/12 "2026-06-02T23:32:49Z")
> [@carlo-bramini](#): > > WSL is unusable for my needs because it doesn’t allow to talk with serial USB devices **It does** , with a little helper, I use that just about every single day. > **[Connect USB devices](https://learn.microsoft.com/en-us/windows/wsl/connect-usb)** > > Learn how to connect a USB device to your WSL 2 Linux distribution using usbipd-win. There are also several GUI helpers for the mouse inclined. ---
**Author:** ![mwichmann](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mwichmann/32/1364_2.png) [@mwichmann](https://discuss.python.org/u/mwichmann)\ **Post date:** [June 4, 2026, 11:40pm UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/13 "2026-06-04T23:40:36Z")
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. ---
**Author:** ![GalaxySnail](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/galaxysnail/32/5655_2.png) [@GalaxySnail](https://discuss.python.org/u/GalaxySnail)\ **Post date:** [June 5, 2026, 6:06am UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/14 "2026-06-05T06:06:49Z")
> [@mwichmann](#): > > […] a platform whose popularity is clearly fading. > […] and it’s clear the level of activity in maintenance and updates is nowhere near what it was in its heyday. As GitHub shows\[1\], I don’t think this is true. Cygwin is still actively developed and receives bug fixes. ![image](https://us1.discourse-cdn.com/flex002/uploads/python1/original/3X/5/3/53bf1f78c4234e2c41ac651917bbd52f319990ec.png) 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. 😉 * * * 1. [https://github.com/cygwin/cygwin/graphs/contributors?from=2000%2F1%2F1](https://github.com/cygwin/cygwin/graphs/contributors?from=2000%2F1%2F1) 2. [x86\_64-pc-cygwin - The rustc book](https://doc.rust-lang.org/rustc/platform-support/x86_64-pc-cygwin.html) 3. [https://releases.rs/docs/1.86.0/#platform-support](https://releases.rs/docs/1.86.0/#platform-support) 4. [https://www.msys2.org/news/#2026-02-01-rust-cygwin-packages-update](https://www.msys2.org/news/#2026-02-01-rust-cygwin-packages-update) ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [June 5, 2026, 6:46am UTC](https://discuss.python.org/t/enhance-cygwin-support/107537/15 "2026-06-05T06:46:29Z")
@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](https://peps.python.org/pep-0011/#unsupported-platforms). If you want to be consulted on Cygwin issues, add yourself to the [platform experts list](https://devguide.python.org/core-team/experts/index.html#platforms). Note that issues with the `OS-unsupported` tag get on a [GH project](https://github.com/orgs/python/projects/27), and (manually, after a delay) [tagged with the platform](https://github.com/orgs/python/projects/27/views/7). 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.