Sorry folks false alarm. It seems that the Imake that generated the
makefiles that GNU make died on was the culprit as it wasn't being built
correctly for some reason and so generated bad rules.
Regards,
Mark Syms
-Original Message-
From: Mark Syms
Sent: Wednesday, May 24,
%% "Michael Sterrett -Mr. Bones.-" [EMAIL PROTECTED] writes:
Re: an issue with GNU make 3.78 and above on DYNIX/ptx...
ms $ gmake --version
ms GNU Make version 3.78.1, by Richard Stallman and Roland McGrath.
ms Built for i386-sequent-sysv4
ms $ uname -a
ms DYNIX/ptx roll
On Wed, 31 May 2000, Paul D. Smith wrote:
OK, I've investigated this further. The reason you never see this
problem on "normal" UNIX systems is that it's not legal for stat(2) to
fail with EINTR. In other words, stat(2) is not interruptible, by
definition, due to signals. Looking at both
%% "Michael Sterrett -Mr. Bones.-" [EMAIL PROTECTED] writes:
ms Do the specifications say that EINTR is not required or that it
ms is forbidden?
Hmm. They say that a function may have more return error codes than
listed in the standards, so you're right: I guess there's nothing
I can confirm that many filesystem operations can fail with EINTR when
operating over NFS. However, someone had to be causing the signals in
question - SIGALRM, maybe, or keyboard SIGINT, etc. Protecting stat() is
usually the most important remedy, since failure will cause you to think
that a
