[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #BLG-266408]: Mar 2010 build on FreeBSD 7.2

Neil,

Thanks for the updates.  I've fixed a few of the small "clean" and "install" 
omissions in the make files.  

After talking about this ar problem with others, I'm going to guess that the 
oalib objects were not being added to gemlib.a because of a timestamp issue.  
In the past people have noticed that "ar" would fail to add all objects to a 
library if the timestamp of some were off, meaning a second instance of ar 
would attempt to add objects to a library before a first instance is complete - 
happens occasionally on extremely fast machines.  Similar to that case, I'm 
guessing that the ar command wasn't run because it appeared that gemlib.a and 
the oalib objects had the same timestamp - at least down to the second, and so 
with the implicit condition being that the objects are add if they are 
*newer*,, it means that if they have the same timestamp as gemlib.a then they 
will *not* be added.  As for a solution, I'm not sure what to do in GEMPAK to 
address this for other users and other systems - you're the first to experience 
this problem - but if it occurs more frequently we'll have to l
 ook as pacing the build somehow.

Michael James
Unidata


> OK. Did just that.
> 
> 2 more failures:
> 
> Recall the first make stopped as reported on problem with failed ar in
> $GEMPAK/source/oalib. So after running "ar rv $OS_LIB/gemlib.a *.o" in
> that directory, the second 'make all' was run from $NAWIPS.
> 
> This second make stopped with:
> /usr/local/bin/gcc43 -DUNDERSCORE -DFreeBSD -I/unidata/Margfort/
> GEMPAK5.11.4/gempak/include -I/unidata/Margfort/GEMPAK5.11.4/os/
> freebsd/include -I/usr/local/include -I/usr/X11R6/include -O -I/
> unidata/Margfort/GEMPAK5.11.4/gempak/source/bridge/dc -I/unidata/
> Margfort/GEMPAK5.11.4/unidata/ldmlog -c dcprof.c
> /usr/local/bin/gfortran43   -fno-second-underscore -fd-lines-as-
> comments -fno-range-check -I/unidata/Margfort/GEMPAK5.11.4/gempak/
> include -I/unidata/Margfort/GEMPAK5.11.4/os/freebsd/include -fno-
> globals -Wno-globals -c dcdopr.f
> f951: error: unrecognized command line option "-Wno-globals"
> f951: error: unrecognized command line option "-fno-globals"
> *** Error code 1
> 
> I then commented out the FOPT_NOGLOB in Makeinc.freebsd:
> #FOPT_NOGLOB = -fno-globals -Wno-globals
> 
> I note that I did not remove the '-Wno-globals' from the NCOPT
> initialization in Makeinc.freebsd.
> 
> After making the above change, the third make completed.
> 
> Then on the first attempt at 'make install', it failed at
> 
> installing in /unidata/Margfort/GEMPAK5.11.4/gempak/source/jwblib
> make: don't know how to make install. Stop
> *** Error code 2
> 
> Stop in /unidata/Margfort/GEMPAK5.11.4/gempak/source.
> *** Error code 1
> 
> I noticed that the Makefile in gempak/source/jwblib does not have an
> "install :" line in it like the other Makefile's in the other
> subdirectories. So I inserted one in this Makefile, returned to
> $NAWIPS and ran 'make install' a second time which did complete
> without error.
> 
> I'll put this in test mode with an ldm for decoding and run thru some
> NTL graphics exercises.
> 
> I see that a 'make clean' stops in gd/goftxt with:
> making clean in /unidata/Margfort/GEMPAK5.11.4/gempak/source/programs/
> gd/goftxt
> make: don't know how to make clean. Stop
> 
> Perhaps these missing 'clean :' and 'install :' issues are an easy fix.
> 
> Thanks for the assistance Michael.
> 
> -Neil
> 
> On Apr 15, 2010, at 3:11 PM, Unidata GEMPAK Support wrote:
> 
> > Yes that should do it.
> >
> >> But if I wanted to 'get on' with things and I ran the ar command as
> >> you show, then would I go back to $NAWIPS and run 'make all' again to
> >> see if it will finish up?
> >>
> >> -Neil
> >>
> >
> > Ticket Details
> > ===================
> > Ticket ID: BLG-266408
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Open
> >
> >
> 
> 


Ticket Details
===================
Ticket ID: BLG-266408
Department: Support GEMPAK
Priority: Normal
Status: Open