[6] in Release_Engineering
perhaps all those unranlib'd libraries are a victim of a ranlib bug?
henry@ATHENA.MIT.EDU (henry@ATHENA.MIT.EDU)
Thu Jun 9 21:28:26 1988
from vs-testers:
From eichin@ATHENA.MIT.EDU Thu Jun 9 21:13:32 1988
Date: Thu, 9 Jun 88 21:10:33 EDT
From: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
To: Win Treese <treese@ATHENA.MIT.EDU>
Cc: Luke VaxHacker <vs-testers@ATHENA.MIT.EDU>
In-Reply-To: Win Treese's message of Thu, 09 Jun 88 20:57:48 EDT <8806100057.AA0
3389@CIROCCO.MIT.EDU>
Subject: Re: 6.0B NFS service...
> Date: Thu, 09 Jun 88 20:57:48 EDT
> From: Win Treese <treese@ATHENA.MIT.EDU>
> I wonder if the 6.0B versions of ranlib and ld are working properly? This
> seems to be happening far too much...
> - Win
I am under a similar impression. The scheme I use to build zwgc(fred)
now creates several small libraries, ranlibs them and links them. They
are failing far too often.
Investigation of my original changes to ranlib showed a small error in
calculating the new offset given that the file timestamp is off; the
skew factor (tfix) is calculated based on the original internal date
stamp, which has already been placed an arbitrary 5 seconds into the
future. Thus, when applying tfix, the result is a library that is
teetering right on the edge of being valid.
Two solutions come to mind: an iterative method which checks and makes
sure that it fixes itself (complex, and bug prone?), or just the
simple method of subtracting the 5 seconds mentioned above to give us
enough leeway "most" of the time.
The change is: (ranlib.c, line 399)
old: tfix = stb.st_mtime - atol(buf); /* How slow are we? */
new: tfix = stb.st_mtime - (atol(buf)-5); /* How slow are we? */
I have been using it most of the afternoon (on a machine whose clock
has drifted back 30 seconds in 24 hours and thus always had to
compensate.) The version in the release failed several times this way,
though not consistently; the version with the -5 compensation has not
failed yet.
_Mark_
