7 comments

[ 2.9 ms ] story [ 23.6 ms ] thread
Are the source code and build instructions used to create these libs available for folks who want to reproduce the standalone artifacts?

This reminds me of why I stopped trying to compile C++ stuff on windows; there are too many incompatible series of MSVC and project compilation can be a major undertaking.

Maven + JDK and Golang build systems aren't perfect, but they tend to be predictable and have worked out a lot better for me across many dimensions. :)

I believe it's this: https://github.com/brechtsanders/winlibs_recipes (MIT) combined with https://github.com/brechtsanders/winlibs_tools (GPLv2). Although as a drive-by observer, if the quality of those "recipes" (and the idea that one needed to cowboy up some shell scripts to build all that stuff versus using a more formal build system) is any indication, I am for sure not the target audience of this project

---

I also had no idea one could have "No commit message" since git has always given me the finger:

  $ git commit --allow-empty -F/dev/null
  Aborting commit due to empty commit message.
Looking at the commit <https://github.com/brechtsanders/winlibs_recipes/commit/0cf2...> I'm guessing it may be some `git am` trickery at work since `git am` does cheerfully apply apply the commit if the subject line is just `[PATCH]`
I missed the answer to: How is this different than MSYS2?

After digging through some of the sublinks:

- You can run gcc in the Command Prompt without using a special shell (MSYS2 has its own shell launcher)

- Maybe MSYS2’s gcc handles exceptions (SEH, etc.) differently

- Lacks a package manager like MSYS2’s pacman (which comes from Arch Linux). But winlibs plans to have something in the future

What did I miss? Would love to see a comparison directly on the home page.

I’m always surprised to remember that mingw32/64 has a dependency on MSVCRT (or now UCRT, I guess).

Given how sparse the C standard library is and how much effort went into/goes into mingw, Cygwin, msys2, and co; you’d assume they would just use the native Win32 APIs and supplement with unversioned/undocumented plain MSVCRT.DLL that is always available on all versions of Windows [0].

[0]: https://github.com/neosmart/msvcrt.lib

It's impressive how the development experience in Windows got worse over the years.. dotnet core saves the face, but the native side of things is abysmal, linux is much better, except for the glibc version BS.. musl to the rescue!
It is really not that bad. Really the only problem is gcc. Clang/LLVM stuff works perfectly fine and if you really wanted you could use MSVC.