Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
xwin
A utility for downloading and packaging the Microsoft CRT headers and libraries, and Windows SDK headers and libraries needed for compiling and linking programs targeting Windows.
-
winget-cli
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).
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
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.
* 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
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.
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
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...>
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.
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/
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
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