On Mon, 2 Apr 2001 20:29:20 -0400, "Paul D. Smith" <[EMAIL PROTECTED]>
wrote:
>%% [EMAIL PROTECTED] (John Alvord) writes:
>
> ja> This is a gnu make 3.79.1, freshly gotten from the archives - date was
> ja> June 2000 if I remember. I am work on upgrading from 3.75 to 3.79.1.
> ja> There were a
The bug you're experiencing WRT modification time in the future is
almost certainly due to Microsoft's long-known bug in their libraries,
which mishandles DST in any year where Apr 1 is a Sunday. This bug has
been reported in the press since at least Jan 1999, but still exists
today even in W2K.
Hello. I am suddenly running into difficulty with the modification-in-
the-future check in 3.75 of Gnu make. I am running on Windows NT 4.0,
and writing to network disk. I am not getting the same error on our
Unix boxes.
I don't actually expect support on the old version, so I downloaded
3.79
%% [EMAIL PROTECTED] (John Alvord) writes:
ja> This is a gnu make 3.79.1, freshly gotten from the archives - date was
ja> June 2000 if I remember. I am work on upgrading from 3.75 to 3.79.1.
ja> There were a few small repairs needed, but it mostly looks OK.
ja> This is on NT 4, using sh.e
GNU make 3.77 is a number of years old; many bugs have been fixed since
it was released.
Please try the latest version (3.79.1) and let us know if there are
still issues.
Thanks.
--
---
Paul D. Smith <[EMAIL PROTECTED
This is a gnu make 3.79.1, freshly gotten from the archives - date was
June 2000 if I remember. I am work on upgrading from 3.75 to 3.79.1.
There were a few small repairs needed, but it mostly looks OK.
This is on NT 4, using sh.exe for a command shell.
Given the following makefile
test:
Hello,
I have found and fixed a bug relating to parameters (switches) begin
passed to the command line. There is a modification in the 3.77 version
which causes errors that was not present in the 3.74 version.
I have include the necessary scripts to reproduce the problem...
You will however nee
Thanks for confirming this Chris.
I found the following article related to "April Fool's
Day 2001" bug:
http://www.pcworld.com/news/article.asp?aid=9327
It's a problem with the runtime library msvcrt.dll,
and it would happen whenever April 1 falls on a
Sunday.
Don't know when(if?) Microsoft rel
It works fine when I set my clock to next week.
> -Original Message-
> From: Arbees [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 02, 2001 2:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Daylight Savings Bug
>
> hey Chris,
>
> can you try one thing? set your system date to be
> a
I got the original; thanks for that and the update.
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesley.org/gmake/
"Please rem
This is an update to a bug fix I sent in last December. I never got a reply
to that one, so I am attaching it to the bottom of this message, just in
case it got lost. This is for GNU Make 3.79.1 under VAX/VMS 7.1.
It turns out that my arscan.c line 82 fix actually does need some adjustment
for
I am having the same problem as [EMAIL PROTECTED] I am using version 3.79.1
for Windows 32. It appears that the time stamp being read by Make as the
current time is one hour in the past. The time stamps on any files
generated by Make are the correct time. I have verified that the BIOS real
tim
%% Arbees <[EMAIL PROTECTED]> writes:
a> And since the day light saving went into effect
a> yesterday (time was moved ahead an hour) I am getting
a> "modification time is in the future" when I run make.
a> Seems like the daylight saving calculations isn't
a> being done? Is this a known
Hi,
I am using make version:
"GNU Make version 3.78.1, by Richard Stallman and
Roland McGrath. Built for Windows32"
And since the day light saving went into effect
yesterday (time was moved ahead an hour) I am getting
"modification time is in the future" when I run make.
Seems like the daylight
14 matches
Mail list logo
