20001220: Missing library archive members under DEC

David,

The "randomness" of this problem appears to have something to do with
disk writes being cached. Since it is appears random, I don't think that
the Makefiles themselves are leading to the problem.

The build can go into a directory, build the files and run "ar" to
add them to the gemlib.a file. Then, make goes into the next directory
and does the same. It appears that the disk write from "ar" may not have
flushed to the disk, and when the next "ar" occurs, the previous information 
is lost.

This is not a parallel make, so "ar" should not return until it is done,
which the logs indicate is true. I find that the missing objects were added to
the archive file in the logs, but then don't appear later.
The build is already faster now that the Makefiles use the -I for
fortran compilation instead of creating the symbolic links.

Maybe Harry knows if DEC has some disk caching I/O tuning parameters.
The CPU seems to want to go ahead without the disk activity.

Steve Chiswell


On Tue, 19 Dec 2000, David Ovens wrote:

> Steve Chiswell wrote:
> > 
> > David,
> > 
> > Our machine is still running OSF4.0f. Once the reomodeling of our
> > office space is complete, our system administrator will set up
> > the new Compaq running 5.0 so that I can test things directly on
> > your platform.
> > 
> > One thing that you could try is completely removing $GEMLIB/sfcntr.a then
> > in the sfcntr director do a " make all install clean". Occasionally, I have
> > found that DEC's "make" program fails to update archive members after 
> > compiling
> > the code.
> 
> Steve,
> 
> "Occasionally" should be replaced in your last sentence with "Constantly,
> but randomly"!  I've spent hours with "make" and on our Compaq
> Tru64 UNIX V5.1 (Rev. 732) machine trying to compile a GEMPAK-5.6.a
> version to test and it keeps failing to update the archive members in
> totally random ways.  Wow, what a pain!  Even "gmake" is having
> problems....but that seems to be a fault with my INCDIR (it wasn't
> finding stdlib.h for imrgin.c in gemlib/im/).
> 
> Thank goodness I can just turn the task of building 5.6.a for the DECs
> over to Harry! :) 
> 
> David
> -- 
> 
> David Ovens           e-mail: address@hidden
> (206) 685-8108          plan: Real-time MM5 forecasting for Pacific Northwest
> Research Meteorologist
> Dept of Atmospheric Sciences, Box 351640
> University of Washington 
> Seattle, WA  98195
>