20051121: McIDAS - Make fails "nowradir"

>From: "Robert Dewey" <address@hidden>
>Organization: ?
>Keywords: 200511210800.jAL80nTf029668 McIDAS build

Hi Robert,

>Institution: UCAR
>Package Version: 2005
>Operating System: Fedora Core 4, 64-Bit
>Hardware Information: Intel 670J 3.8GHz (64-Bit), 512MB DDR2 RAM, 40GB HDD
>Inquiry:

re:
>I am trying to compile McIDAS-X 2005, and I keep getting stopped with
>the "nowradir" failure. I searched it up using the "glimpse" search,
>and came across a similar problem with McIDAS-X 2004, but the solution
>to that problem didn't solve mine.

The problem is being seen on newer versions of Linux (not just FC4) on
machines with fast CPUs.  What is happening is that one or more object
modules are not getting added to libraries that are built by the make
process.  In your case, the object module nowrutil.o is not being added
to libsdi.a.

One "fix" (work around) is:

<as 'mcidas'>
cd ~mcidas/mcidas2005/src
ar r libsdi.a nowrutil.o
ranlib libsdi.a
make

A different approach:

I have recently modified the McIDAS archiving script mcar.sh to add
pauses after invocations of 'ar' and 'ranlib':

<in ~mcidas/mcidas2005/src modify mcar.sh>

change:

  #-------
  # add the objects to the library
  #-------
  
  ar r${ar_l} $lib ${1+"$@"} || exit 1
  
  #-------
  # run a ranlib(1) if necessary
  #-------

$ranlib $lib

to:

  #-------
  # add the objects to the library
  #-------
  
  ar r${ar_l} $lib ${1+"$@"} || exit 1
  # <<<<< UPC add 20051103 - wait for memory cache to flush to disk >>>>>
  sleep 5
  
  #-------
  # run a ranlib(1) if necessary
  #-------
  
  $ranlib $lib
  # <<<<< UPC add 20051103 - wait for memory cache to flush to disk >>>>>
  sleep 1

>I am thinking there is a problem/bug in "Fedora Core 4", as McIDAS
>compiled just fine on "Fedora Core 2" not more than a few hours ago.

The problem is being found on most new releases of Linux.  I think that
'ar' has a bug such that it is not flushing system memory buffers to
the file it is working on before exiting.

>Perhaps it's because I am running this machine using 64-Bit
>architecture?

I build McIDAS-X v2005 on my work machine which is a dual Xeon EM64T
(64-bit) Dell that is running Fedora Core 4 64-bit Linux.  I too
saw the problem of object modules not being added to libraries
built during the make process.  Modification of mcar.sh has worked
for me with no problems and at one user site who is running FC4
on fast 32-bit Intel machines.

>With all the troubles and bugs of upgrading to newer operating systems,
>I'm thinking that staying behind a release or two is probably a good
>option right about now...

I would agree in principle that it is not always the best idea to
upgrade to the latest release of an OS.  The tricky part, however, is
keeping current with security updates that are important.  I am having
no problems with FC4 on my work machine or on the machine I use
at home for development (a slow 700 Mhz PIII).

>Also, I attached the makelog just in case something else is going that
>I didn't catch...

Your makelog told me that nexrutil.o did not get added to libmcidas.a
even though it was built and 'ar' was run to add it.  Here are
the operative parts of your makelog:

rm -f nexrutil.o
gcc -c -O -I. -I../netcdf/libsrc -I../hdf/hdf/src -I../hdf/mfhdf/libsrc 
-I../jpeg -I../zlib -I../tiff/libtiff -I../libgeotiff nexrutil.c
nexrutil.c: In function ReadNexrInfo:
nexrutil.c:1526: warning: pointer targets in assignment differ in signedness
compile nexrutil.c:             done

and:

./mcar libsdi.a BitUtil.o Bk11Data.o crc16.o GVAR.o m0tenoff.o m0twelveoff.o 
MSAT.o NCDF.o giniutil.o nexrutil.o POES.o SDIConv.o SDIUtil.o servutil.o TIP.o

The first snippit shows that nexrutil.o was created, and the second shows
that it should have been added to libsdi.a.

NOTE:  you may find that other object modules did not get added to
libraries built during the make process.  You will need to manually add
them (to the correct library) in the same manner as the example I
included above.  The other alternative, is for you to edit your mcar.sh
and make the changes I indicated above and then restart your build from
scratch:

<as 'mcidas'>
-- edit mcar.sh as per example above
make clobber
make

I would appreciate if you would, in fact, take this route since it will
either confirm or disprove my "fix".  Thanks in advance for doing this,
and please let me know the results of rebuilding after modifying mcar.sh.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.

>From address@hidden  Mon Nov 21 10:17:19 2005

Hello Tom,

As you requested, I did the "mcar.sh" fix... I can confirm that it
worked and that McIDAS 2005 has been successfully built/installed on my
machine.

Thanks again,

Robert Dewey