Because cross-compiling binaries for Windows is easier than building natively

1. glibc_version_header

   1 9 835 0.0 C++

   Build portable Linux binaries without using an ancient distro

   

   There are other approaches like https://github.com/wheybags/glibc_version_header or sysroots with older glibc, e.g. https://wiki.gentoo.org/wiki/Crossdev - you don't need your whole XP, just the the system libs to link against.

   Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.

2. CodeRabbit

   coderabbit.ai featured

   CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.

   

3. mach

   2 38 3,799 9.6 Zig

   zig game engine & graphics toolkit

   

   * Linux (arm): 15 MiB

   That's full cross compilation of WebGPU GUI applications to all desktop platforms in under ~217 MiB for most platforms.

   [0] https://machengine.org

4. project-azua

   3 1 246 1.8 Python

   Data Efficient Decision Making

   

5. xwin

   4 5 456 7.7 Rust

   A utility for downloading and packaging the Microsoft CRT & Windows SDK headers and libraries needed for compiling and linking programs targeting Windows.

   

   There's tooling that mostly avoids this. https://github.com/Jake-Shadle/xwin

   This is a utility that fixes a lot of the cross-compiling issues for windows by giving you a portable, unfucked naming, and not-massive SDK. It's the same SDK you get when you install MSVC but it's only a few hundred megs and the names are consistent even with all of Windows' fucked up tooling.

   The only caveat is you need to provide your own compiler, in this case clang is often the best option.

6. winget-cli

   5 291 23,941 9.4 C++

   WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).

   

7. zig

   6 869 38,110 10.0 Zig

   General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

   

   I was sad to find out "Zig supports only the last three macOS versions". No ncdu2 for me :(

   https://github.com/ziglang/zig/pull/10232#issue-1064864004

8. WSL

   7 416 18,033 8.3 Python

   Issues found on WSL

   

   This one? I remember it as an earnest description of the difficulties the WSL team had with the speed of NTFS - and I think it was one of the reasons for the switch to virtualisation in WSL2.

   <https://github.com/Microsoft/WSL/issues/873#issuecomment-425...>

9. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

10. llvm-mingw

    8 17 2,165 9.0 C

    An LLVM/Clang/LLD based mingw-w64 toolchain

    

    Sadly Qt ships MinGW 8.1 which is positively ancient (released in 2018). If you're starting a new project (which you likely are if you are installing an IDE aha) there's no reason not to go for more recent compilers - msys2 has GCC12 (https://packages.msys2.org/package/mingw-w64-x86_64-gcc) and Clang 14 (https://packages.msys2.org/package/mingw-w64-x86_64-clang) which just work better overall, have much more complete C++20 support, have less bugs, better compile times (especially clang with the various PCH options that appeared in the last few versions), better static analysis, etc.

    Personally I use https://github.com/mstorsjo/llvm-mingw's releases directly which does not require MSYS but that's because I recompile all my libraries with specific options - if the MSYS libs as they are built are good for you there's no reason not to use them.

11. mxe

    9 9 1,229 9.6 Makefile

    MXE (M cross environment)

    

    I used to use MXE [1] to compile fully static Windows binaries on Linux VMs hosted with Travis. It needed to crane in everything though, so it was a source of bottlenecks from time to time. I was also uncertain about the provenance of a lot of the dependencies in that toolchain. So when Travis died I took the opportunity to move Windows builds back to gnu with msys2, all over GH Actions. These are actually comparatively snappy and I’m reasonably satisfied with it.

    [1] https://mxe.cc/

12. BinaryBuilder.jl

    10 5 395 7.3 Julia

    Binary Dependency Builder for Julia

    

    There is the Julia package https://github.com/JuliaPackaging/BinaryBuilder.jl which creates an environment that fakes being another, but with the correct compilers and SDKs . It's used to build all the binary dependencies

13. osxcross

    11 26 3,022 5.2 C++

    Mac OS X cross toolchain for Linux, FreeBSD, OpenBSD and Android (Termux)

    

14. manylinux

    12 15 1,513 9.3 Shell

    Python wheels that work on any linux (almost)

    

    It's very hard. Incompatible glibc ABIs make this nigh impossible, there's a reason Steam installs a vcredistributable.dll for pretty much every game on Windows.

    Look no further than the hoops you need jump through to distribute a Linux binary on PyPI [1]. Despite tons of engineering effort, and tons of hoop jumping from packagers, getting a non-trivial binary to run across all distros is still considered functionally impossible.

    [1]: https://github.com/pypa/manylinux

15. cygwin-rurban

    13 1 0 10.0 Diff

    Automatically exported from code.google.com/p/cygwin-rurban

    

Suggest a related project