Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32377

Re: 32 bits time_t and Y2038 issue

Show all headers | View raw

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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 16:22 +0100
  Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-11 17:32 +0100
    Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 23:21 +0100
      Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 10:33 +0100
        Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 16:48 +0100
          Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 17:39 +0100
            Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 18:13 +0100
              Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 19:18 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-13 09:57 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-13 16:51 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 13:27 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-14 14:20 +0100
    Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 08:44 +0100
      Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 11:14 +0100
      Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-14 01:48 +0000
        Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 08:36 +0100
    Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 16:30 +0000
      Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-15 17:02 +0000
        Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 23:26 +0000
      Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 09:21 +0100
        Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 11:34 +0100
          Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 17:31 +0100
            Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:29 +0100
              Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:20 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 13:54 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 20:53 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 11:19 +0100
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:35 +0000
          Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:28 +0000
            Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:43 +0100
              Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-18 20:58 +0000
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-18 23:31 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 11:24 +0100
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 14:27 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 17:33 +0100
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 19:08 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 21:14 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:48 +0000
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-21 13:27 +0000
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-19 22:09 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-20 09:26 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:40 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:23 +0000
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-21 22:38 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 08:24 +0100
              Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:04 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 16:45 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:51 +0100
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-22 00:00 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 14:29 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-22 14:46 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 17:57 +0100
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-22 15:57 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 18:02 +0100
        Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:44 +0000

csiph-web