6 ms·

Exacly.. I avoid Visual Studio.. I try to build everthing using Mingw..

by Borg3 8mo ago

xvilka 8mo ago
Clang is the better alternative to MinGW because it can use standard Windows libraries and avoids the need for additional runtime.
- reactordev 8mo ago
  Just msys2 it all
  - delta_p_delta_x 8mo ago
    MSYS2 is horrible. It brings a massive runtime environment and is a bad idea to foist on users.
    - michaelsbradley 8mo ago
      Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)? The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.
      - reactordev 8mo ago
        He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…
        okanat 8mo ago
        MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw. Git installs its own Mingw and Msys2 stuff but mostly compiled for a Mingw environment so they consume Windows paths natively instead of using MSYS2/Cygwin path conversion. That's why when you have mixed PATH variable all hell breaks loose with Git.
        delta_p_delta_x 8mo ago
        > MSYS2 just enough development environment Doesn't it come with `pacman` too?
        michaelsbradley 8mo ago
        Yes, it’s wonderful.
        okanat 8mo ago
        You need to update stuff somehow. `pacman` is a beautifully simple package manager. It covers the complexity just enough without going overboard.
        michaelsbradley 8mo ago
        I think you’re underestimating or discounting the work the MSYS2 team put into their layered environments mechanism: https://www.msys2.org/docs/environments/ https://www.msys2.org/docs/environments/
        okanat 8mo ago
        I do appreciate it as a daily user of MSYS2. However the bigger thing that enabled them is indeed Cygwin project since it unlocked the path to build things that are using strict Unix tooling. autoconf, Make, bash etc cannot run under a pure Windows environment. They are too dependent to the underlying system being a Unix. To use pacman, bash and make in MSYS2, you need msys-2.0.dll. Even they cite Cygwin's URL in the runtime package [1]. And they basically patch Cygwin to enable this [2] Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays. The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals. [1] "Cygwin POSIX emulation engine", https://packages.msys2.org/base/msys2-runtime https://packages.msys2.org/base/msys2-runtime [2] https://github.com/msys2/MSYS2-packages/tree/master/msys2-runtime https://github.com/msys2/MSYS2-packages/tree/master/msys2-ru...
      - delta_p_delta_x 8mo ago
        It was not clear what the parent commenter was addressing; I was under the impression they meant 'compile against the MSYS2 environment', which is broadly Cygwin, yes, which should not be forced onto a user.
        michaelsbradley 8mo ago
        Okay, but that just seems to be perpetuating the misunderstanding of what MSYS2 is intended for. It gives you a *nix-like shell/dev environment and tools, but you build native software that runs on Windows systems that don’t have or need to have all/parts of MSYS2/Cygwin installed.
        michaelsbradley 8mo ago
        Example: I built a network daemon using the MSYS2 CLANG64 environment and llvm toolchain on Windows 10. Windows 7 x64 users could download the compiled single-file executable and run it just fine, so long as they installed Microsoft’s Universal C Runtime, which is a free download from Microsoft’s website.
        delta_p_delta_x 8mo ago
        > MSYS2 CLANG64 I get your point. Although my point is that there is actually zero need for MSYS at all for this, even as a developer, and especially not with the 'CLANG64' environment. These binaries themselves are built to run in the MSYS2 environment This is how I cross-compile from Windows... to Windows with LLVM-MinGW[1]: > (gci Env:PATH).Value.Split(';') | sort > clang-21.exe --version clang version 21.1.2 (https://github.com/llvm/llvm-project.git b708aea0bc7127adf4ec643660699c8bcdde1273) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: C:/Users/dpdx/AppData/Local/Microsoft/WinGet/Packages/MartinStorsjo.LLVM-MinGW.UCRT_Microsoft.Winget.Source_8wekyb3d8bbwe/llvm-mingw-20250924-ucrt-x86_64/bin Configuration file: C:/Users/dpdx/AppData/Local/Microsoft/WinGet/Packages/MartinStorsjo.LLVM-MinGW.UCRT_Microsoft.Winget.Source_8wekyb3d8bbwe/llvm-mingw-20250924-ucrt-x86_64/bin/x86_64-w64-windows-gnu.cfg [1]: https://github.com/mstorsjo/llvm-mingw https://github.com/mstorsjo/llvm-mingw
- dwroberts 8mo ago
  Can you actually do cross compilation (on Linux host to win64 binary) with clang in the same way as MingW does out of the box though?
  - okanat 8mo ago
    No. You cannot even do direct compilation on the same host and target with clang only. LLVM doesn't come with the C library headers (VCRuntime) or the executable runtime startup code (VCStartup).Both of which are under Visual Studio proprietary licenses. So to use Clang on Windows without Mingw, you need Visual Studio.
- jezek2 8mo ago
  I use MingW without any extra libs (no msys), it just uses the ancient msvcrt.dll that is present in all Windows versions, so my programs work even on Windows 2000. Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.
  - okanat 8mo ago
    You can use Mingw-w64 UCRT or CLANG environments that come with MSYS2. Compared to older Mingw64 environments those link with the latest UCRT so you get almost the same style executable as Visual Studio. The only difference for C is that it uses Mingw exception handling and global initialization code, and it uses Itanium ABI for C++.
    - jezek2 8mo ago
      But that's the point, I don't want the same style executable as Visual Studio. Having to distribute bunch of DLLs and having worse compatibility is pretty bad. A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.
      - reactordev 8mo ago
        yeah, you can get away with this now a days because Git itself installs 2/3rds of the things you need anyway. You just need to finish the job by getting the package and putting the binaries in your git folder. Bam! mingw64, clang, what ever cc you need. It all links to standard windows stuff because you have to tell the linker where your win32.lib is. But this is true no matter the compiler, it's just Visual Studio supplies this in some god awful Program Files path.
- 1718627440 8mo ago
  MSYS2 UCRT also uses the native Windows libraries (aka. UCRT).

Exacly.. I avoid Visual Studio.. I try to build everthing using Mingw..

by Borg3 8mo ago

Exacly.. I avoid Visual Studio.. I try to build everthing using Mingw..

Clang is the better alternative to MinGW because it can use standard Windows libraries and avoids the need for additional runtime.

reactordev 8mo ago
Just msys2 it all
- delta_p_delta_x 8mo ago
  MSYS2 is horrible. It brings a massive runtime environment and is a bad idea to foist on users.
  - michaelsbradley 8mo ago
    Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)? The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.
    - reactordev 8mo ago
      He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…
      - okanat 8mo ago
        MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw. Git installs its own Mingw and Msys2 stuff but mostly compiled for a Mingw environment so they consume Windows paths natively instead of using MSYS2/Cygwin path conversion. That's why when you have mixed PATH variable all hell breaks loose with Git.
        delta_p_delta_x 8mo ago
        > MSYS2 just enough development environment Doesn't it come with `pacman` too?
        michaelsbradley 8mo ago
        Yes, it’s wonderful.
        okanat 8mo ago
        You need to update stuff somehow. `pacman` is a beautifully simple package manager. It covers the complexity just enough without going overboard.
        michaelsbradley 8mo ago
        I think you’re underestimating or discounting the work the MSYS2 team put into their layered environments mechanism: https://www.msys2.org/docs/environments/ https://www.msys2.org/docs/environments/
        okanat 8mo ago
        I do appreciate it as a daily user of MSYS2. However the bigger thing that enabled them is indeed Cygwin project since it unlocked the path to build things that are using strict Unix tooling. autoconf, Make, bash etc cannot run under a pure Windows environment. They are too dependent to the underlying system being a Unix. To use pacman, bash and make in MSYS2, you need msys-2.0.dll. Even they cite Cygwin's URL in the runtime package [1]. And they basically patch Cygwin to enable this [2] Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays. The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals. [1] "Cygwin POSIX emulation engine", https://packages.msys2.org/base/msys2-runtime https://packages.msys2.org/base/msys2-runtime [2] https://github.com/msys2/MSYS2-packages/tree/master/msys2-runtime https://github.com/msys2/MSYS2-packages/tree/master/msys2-ru...
    - delta_p_delta_x 8mo ago
      It was not clear what the parent commenter was addressing; I was under the impression they meant 'compile against the MSYS2 environment', which is broadly Cygwin, yes, which should not be forced onto a user.
      - michaelsbradley 8mo ago
        Okay, but that just seems to be perpetuating the misunderstanding of what MSYS2 is intended for. It gives you a *nix-like shell/dev environment and tools, but you build native software that runs on Windows systems that don’t have or need to have all/parts of MSYS2/Cygwin installed.
        michaelsbradley 8mo ago
        Example: I built a network daemon using the MSYS2 CLANG64 environment and llvm toolchain on Windows 10. Windows 7 x64 users could download the compiled single-file executable and run it just fine, so long as they installed Microsoft’s Universal C Runtime, which is a free download from Microsoft’s website.
        delta_p_delta_x 8mo ago
        > MSYS2 CLANG64 I get your point. Although my point is that there is actually zero need for MSYS at all for this, even as a developer, and especially not with the 'CLANG64' environment. These binaries themselves are built to run in the MSYS2 environment This is how I cross-compile from Windows... to Windows with LLVM-MinGW[1]: > (gci Env:PATH).Value.Split(';') | sort > clang-21.exe --version clang version 21.1.2 (https://github.com/llvm/llvm-project.git b708aea0bc7127adf4ec643660699c8bcdde1273) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: C:/Users/dpdx/AppData/Local/Microsoft/WinGet/Packages/MartinStorsjo.LLVM-MinGW.UCRT_Microsoft.Winget.Source_8wekyb3d8bbwe/llvm-mingw-20250924-ucrt-x86_64/bin Configuration file: C:/Users/dpdx/AppData/Local/Microsoft/WinGet/Packages/MartinStorsjo.LLVM-MinGW.UCRT_Microsoft.Winget.Source_8wekyb3d8bbwe/llvm-mingw-20250924-ucrt-x86_64/bin/x86_64-w64-windows-gnu.cfg [1]: https://github.com/mstorsjo/llvm-mingw https://github.com/mstorsjo/llvm-mingw
dwroberts 8mo ago
Can you actually do cross compilation (on Linux host to win64 binary) with clang in the same way as MingW does out of the box though?
- okanat 8mo ago
  No. You cannot even do direct compilation on the same host and target with clang only. LLVM doesn't come with the C library headers (VCRuntime) or the executable runtime startup code (VCStartup).Both of which are under Visual Studio proprietary licenses. So to use Clang on Windows without Mingw, you need Visual Studio.
jezek2 8mo ago
I use MingW without any extra libs (no msys), it just uses the ancient msvcrt.dll that is present in all Windows versions, so my programs work even on Windows 2000. Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.
- okanat 8mo ago
  You can use Mingw-w64 UCRT or CLANG environments that come with MSYS2. Compared to older Mingw64 environments those link with the latest UCRT so you get almost the same style executable as Visual Studio. The only difference for C is that it uses Mingw exception handling and global initialization code, and it uses Itanium ABI for C++.
  - jezek2 8mo ago
    But that's the point, I don't want the same style executable as Visual Studio. Having to distribute bunch of DLLs and having worse compatibility is pretty bad. A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.
    - reactordev 8mo ago
      yeah, you can get away with this now a days because Git itself installs 2/3rds of the things you need anyway. You just need to finish the job by getting the package and putting the binaries in your git folder. Bam! mingw64, clang, what ever cc you need. It all links to standard windows stuff because you have to tell the linker where your win32.lib is. But this is true no matter the compiler, it's just Visual Studio supplies this in some god awful Program Files path.
1718627440 8mo ago
MSYS2 UCRT also uses the native Windows libraries (aka. UCRT).