Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32373

Re: 32 bits time_t and Y2038 issue

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: 32 bits time_t and Y2038 issue
Date 2025-03-18 20:43 +0100
Organization A noiseless patient Spider
Message-ID <vrcidh$35fbp$2@dont-email.me> (permalink)
References (1 earlier) <vqpoi3$226ih$1@dont-email.me> <slrnvtbaot.sal.news-1513678000@a-tuin.ms.intern> <vrbado$2133a$1@dont-email.me> <vrbi79$2a30t$1@dont-email.me> <slrnvtjeq9.566.news-1513678000@a-tuin.ms.intern>

Show all headers | View raw

On 18/03/2025 19:28, Michael Schwingen wrote:
> On 2025-03-18, David Brown <david.brown@hesbynett.no> wrote:
>> Install msys2 (and the mingw-64 version of gcc, if you want a native
>> compiler too).  Make sure the relevant "bin" directory is on your path.
>> Then gnu make will work perfectly, along with all the little *nix
>> utilities such as touch, cp, mv, sed, etc., that makefiles sometimes use.
>>
>> The only time I have seen problems with makefiles on Windows is when
>> using ancient partial make implementations, such as from Borland, along
>> with more advanced modern makefiles, or when someone mistakenly uses
>> MS's not-make "nmake" program instead of "make".
> 
> I have seen problems when using tools that are build during the compile
> proess, used to generate further C code.

I have several projects where C code is generated automatically (such as 
with a Python script that turns an image file into a const uint8_t array).

In the days of FAT filesystems - 16-bit Windows and DOS, primarily - it 
was possible to get issues with that kind of thing along with the weaker 
"make" implementations included with Borland tools and the like.  The 
big issue was the timestamp resolution for files was too coarse.

> 
> I would suggest using WSL instead of msys2. I have not used it for
> cross-compiling, but it works fine (except for file access performance) for
> my documentation process, which needs commandline pdf modification tools
> plus latex.
> 

I would not suggest WSL unless you are trying to re-create a full Linux 
environment - since that is what WSL is.  It is a virtual machine with 
Linux.  If you have a complex setup with *nix features like soft links, 
or filenames with Windows-hostile characters, or want to use 
/dev/urandom to generate random data automatically in your build 
process, then use WSL.  (Or just switch to Linux.)

msys2 is totally different.  The binaries are all native Windows 
binaries, and they all work within the same Windows environment as 
everything else.  There are no problems using Windows-style paths 
(though of course it is best to use relative paths and forward slashes 
in your makefiles, #include directives, etc., for cross-platform 
compatibility).  You can use the msys2 programs directly from the normal 
Windows command window, or Powershell, or in batch files, or directly 
from other Windows programs.

I have also used pdf modification tools and pdfLaTeX (Miktex) on 
Windows, controlled by make, from msys.  (It's been a while, so it was 
probably msys make rather than msys2 make.)

I do most of that kind of thing from Linux - amongst other things, it is 
faster on the same hardware for all of this stuff.  But I like my builds 
to work on Windows as well as Linux.

>> A good makefile picks up the new files automatically and handles all the
>> dependencies, so often all you need is a new "make -j".
> 
> I don't do that anymore - wildcards in makefiles can lead to all kinds of
> strange behaviour due to files that are left/placed somewhere but are not
> really needed.

I'm sure you can guess the correct way to handle that - don't leave 
files in the wrong places :-)

> I prefer to list the files I want compiled - it is not that
> much work.
> 

In a project of over 500 files in 70 directories, it's a lot more work 
than using wildcards and not keeping old unneeded files mixed in with 
source files.

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