Re: 32 bits time_t and Y2038 issue

On 18/03/2025 23:31, Hans-Bernhard Bröker wrote:

Am 18.03.2025 um 21:58 schrieb Grant Edwards:

On 2025-03-18, David Brown <david.brown@hesbynett.no> wrote:
>

msys2 is totally different.  The binaries are all native Windows
binaries, and they all work within the same Windows environment as

[...]
 

Are the make recipes are run using a normal Unix shell (bash? ash?
bourne?) with exported environment variables as expected when running
'make' on Unix?

 Pretty much, yes.  There are some gotchas in handling of path names, and particularly their passing to less-than-accomodating, native Windows compilers etc..  And the quoting of command line arguments can become even dicier than native Windows already is.
 There be dragons, but MSYS2 will keep the vast majority of them out of your sight.
 

Exactly - there are a lot fewer dragons, and they are smaller, than with other solutions.  If you try to use path names with very long names, spaces, names like "*", or with embedded quotation marks, or the dozen characters that Windows doesn't like, then you are asking for trouble. But those cause trouble on Windows no matter what.
You can certainly make your life easier by avoiding ridiculous path names.  Put your compilers in directories under "c:/compilers/", or whatever, so that you can easily find them and refer to them.  And put your projects in "c:/projects/".  It is unfortunate that Windows uses downright insane paths by default for installed programs and for user documents, but you don't have to follow those.
You can still use msys2, and make, even with ridiculous path names, but you need to be more careful to get your filename quoting right.

The gnu make functions [e.g $(shell <whatever>)] all work as epected?

 Yes, as long as you stay reasonable about the selection of things you try to run that way, and keep in mind you may have to massage command line arguments if <whatever> is a native Windows tool.
 For reference, MSYS2 is also the foundation of Git Bash for MS Windows, which you might be familiar with already...
 

msys2 / mingw-64 is the basis for most modern gcc usage on Windows (mingw-64 is the gcc "target" and has the standard library, while msys2 provides a substantial fraction of POSIX / Linux compatibility along with vast numbers of common utility programs and libraries).  When you install the GNU ARM Embedded toolchain, it is built by and for mingw-64.   When you install NXP's IDE, or Atmel Studio, or pretty much any other vendor development tool, all the *nix world tools on it will be compiled for old mingw or modern mingw-64, and many will be taken directly from old msys or modern msys2.  There are a few IDE's that now use cmake and ninja, but for most of them, when you select "build" from the menus, the IDE generates makefiles then runs an mingw / msys build of gnu make. Those who think you have to use an IDE on Windows and make does not work, are already using make !

The underlying technology of MSYS2 is a fork of the Cygwin project, which is an environment that aims to provide the best emulation of a Unix environment they can, inside MS Windows.  The key difference of the MSYS2 fork lies in a set of tweaks to resolve some of the corner cases more towards the Windows interpretation of things.
 

I believe they made more changes than that.  Cygwin used to suffer from three major problems - it's focus on POSIX compatibility made it highly inefficient, it used unix-like behaviour that was alien to Windows (like /cygdrive/c/... paths), and it suffered from a level of DLL hell beyond anything seen on other Windows programs.  This last point made things very difficult if you only wanted a few cygwin-based programs.  The original msys and mingw projects were a lot simpler, but stagnated and failed to support 64-bit targets and even C99.  msys2 and mingw-64 were made to get the best of both worlds, taking parts from each of these projects and adding their own.

So, if your Makefiles are too Unix centric for even MSYS2 to handle, Cygwin can probably still manage.  And it will do it for the small price of many of your relevant files needing to have LF-only line endings.
 

There are certainly a few things that Cygwin can handle that msys2 cannot.  For example, cygwin provides the "fork" system call that is very slow and expensive on Windows, but fundamental to old *nix software.  msys2 (and msys before it) do not support "fork".  This is not an issue for the solid majority of modern *nix software, because threading and "vfork / execve" replaced most use-cases for "fork" in the last twenty years.
But you can happily use lots of unix-like things from msys2.  If you want 16 bytes of random data in your program, you can write:
head -c 16 /dev/random | hexdump -v -e '/i "%02x, "' > rand.inc
and use it as :
const uint8_t random_data = {
#include "rand.inc"
};
The "head..." line will work fine from the normal Windows command line, or an msys2 bash shell, or a makefile, or whatever.

Here's a rough hierarchy of Unix-like-ness among Make implementations on a PC, assuming your actual compiler tool chain is a native Windows one:
 0) your IDE's internal build system --- not even close

In most cases - at least for IDE's I have had from microcontroller vendors - the IDE's internal build system /is/ make.  It is a normal msys2 make (albeit often not the latest version).  The IDE's "internal build" generates makefiles automatically (a bit slowly and inefficiently for big projects), then runs "make".
Of course, you don't get to work with these makefiles directly, so you can't use any of the more interesting features of make - any changes you make to the generated makefiles will be overwritten on the next build.

1) original DOS or Windows "make" tools

That varied from supplier to supplier, since DOS and Windows don't have any kind of native development tools.  Borland and MS both provided "make" utilities with basic features but lots of limitations compared to the *nix world.  Other tool vendors may have been different.

2) fully native ports of GNU make (predating MSYS)
3) GNU Make in MSYS2
4) GNU Make in Cygwin
5) WSL2 --- the full monty
 I'll also second an earlier suggestion: for newcomers with little or no present skills in Makefile writing, CMake or Meson can be a much smoother entry into this world.  Also, if you're going this route, I suggest to consider skipping Make and using Ninja instead.
 

Ninja is the assembly language of build tools - it is meant to be fast to run, but people are not expected to write ninja files manually.  You generate them with cmake or other tools.
cmake is certainly a popular modern build system, but I personally have never got into it.  It strikes me as massively over-complex and very fragile - it always seems to need very specific versions of cmake, which in turn require very specific versions of a hundred different dependencies.  Maybe in a decade or so it will have stabilised enough that the same cmake setup can be used reliably on multiple different systems, but it has a /long/ way to go before then.  Perhaps I am being unfair to cmake here due to lack of experience, but I have yet to see a point to it.
Meanwhile, I can (and do) build my projects on four or five different Linux systems and a couple of Windows machines, all of wildly different generations, using the same makefile and a copy of either the Linux or the Windows directories containing the appropriate GNU ARM Embedded toolchain.  All I need to modify is a host-specific pointer to the toolchain directory.