20000914: 20000914: 20000914: compile error on Linux for McIDAS-X

>From: Robert Benites <address@hidden>
>Organization: UNCA
>Keywords: 200009141532.e8EFWQb27728 McIDAS-X servutil.c Linux

Bob,

>Here's the tail end of the makelog that has to with the decoder:
>
>##########################################
>Thu Sep 14 17:06:26 EDT 2000: BUILD BEGIN
>##########################################
>
>./mccomp -O -s -vendor -o decoder decoder.o -L. -lsdi -lmcidas
>mcfc -s -O -o decoder decoder.o -L. -L/usr/local/lib -L/usr/X11R6/lib -lsdi -l
> mc
>idas -lf2c -ldl -lm
>decoder.o: In function `getflt':
>decoder.o(.text+0x3b6): undefined reference to `scalb'
>link    decoder:                done

Ah ha!  I looked through our tracking system section for McIDAS:

http://www.unidata.ucar.edu/glimpsedocs/ghmcidas.html

using 'scalb' as a search key and found the only indication of this being
a problem for users.  Interestingly, the exchange I found was between
myself and Jim Heimbach!  Here is the text of that inquiry:


  >./mccomp -I. -I../netcdf/libsrc -c decoder.cp
  >gcc -c -O -ansi -D_GNU_SOURCE -I/usr/X11R6/include -I. -I../netcdf/libsrc 
deco
  > der.c
  >decoder.c: In function `decode_block':
  >decoder.c:438: warning: assignment makes pointer from integer without a cast
  >decoder.c: In function `notify':
  >decoder.c:715: warning: assignment makes pointer from integer without a cast
  >decoder.c: In function `main':
  >decoder.c:1220: `optarg' undeclared (first use this function)
  >decoder.c:1220: (Each undeclared identifier is reported only once
  >decoder.c:1220: for each function it appears in.)
  >decoder.c:1236: `optind' undeclared (first use this function)
  >decoder.c:1260: warning: assignment makes pointer from integer without a cast
  >decoder.c:1265: `optopt' undeclared (first use this function)
  >decoder.c:1391: warning: assignment makes pointer from integer without a cast
  >decoder.c:1468: warning: assignment makes pointer from integer without a cast
  >compile        decoder.cp:             FAILED
  >
  >=====================================================================
  
  Hmm...  7.5 builds with no problems on our RedHat 5.2 system here at Unidata,
  so this seems like it might be a Slackware "thing".
  
  I logged onto yor system and tried adding some explicit declarations
  to decoder.cp:
  
  /* <<<<< UPC mod 990518 -- Slackware Linux Begin >>>>> */
  extern char *optarg;
  extern int optint, opterr, optopt;
  /* <<<<< UPC mod 990518 -- Slackware Linux End >>>>> */
  
  This allowed decoder.cp to be compiled, but the build would fail during
  the link phase.  'makelog' indicated that the problem was an undefined
  reference to 'scalb':
  
  decoder.o: In function `getflt':
  decoder.o(.text+0x3b6): undefined reference to `scalb'
  link    decoder:                done
  
  I checked out RedHat Linux system and see that 'scalb' has a man page
  and is included in libm.a.  The same is _not_ true on your system, and
  I couldn't find out if/where it might be defined.  Given this, I took
  the quick and dirty route of:
  
  cd ~mcidas/mcidas7.5/src
  touch decoder
  make all
  
  The reason that I am not too worried about this is that 'decoder' (the
  executable produced from the compilation/link of 'decoder.cp' is only
  used by the SDI routines in the McIDAS distribution.  For reference,
  SDI is Satellite Data Ingestor, and Unidata users do not have these
  kind of boxes (direct ingest of GOES, etc. on computers with special
  hardware installed in PCI bus master slots).  The bottom line is 'decoder'
  is not something you would ever use, so it being empty will make no 
  difference to you.

So, decoder.cp compiling under Slackware continuest to be a problem.


>##########################################
>Thu Sep 14 17:06:32 EDT 2000: BUILD END
>##########################################
>
>Per your instructions I did a touch of decoder and then did another
>make install.all and it went along for quite some time till I saw:
>
>if [ ! -f /home/mcidas/tcl/bin/tclsh ]; then                    \
>                TV=`grep "^TCL_VERSION" ../tcl/unix/tclConfig.sh |     \
>                sed "s/^.*'\([^']*\)'.*$/\1/"` && \
>                cd /home/mcidas/tcl/bin &&                      \
>                if [ -f tclsh$TV ]; then                \
>                         rm -f tclsh;                    \
>                         ln -s tclsh$TV /home/mcidas/tcl/bin/tclsh;     \
>                else                                    \
>                         echo "No tclsh found in /home/mcidas/tcl/bin!"; \
>                         exit 1;                         \
>                fi;                                     \
>                fi
>/bin/sh: /home/mcidas/tcl/bin: No such file or directory
>make: *** [/home/mcidas/tcl/bin/tclsh] Error 1

This is a weird one.  If the HOME directory of 'mcidas' is /home/mcidas,
then there should be a /home/mcidas/tcl and /home/mcidas/tcl/bin directory
created by the installation procedure.  Now, if the Tcl/Tk portion of the
build was done previously (and it was), AND if the HOME directory of the
McIDAS has been changed since, OR if the McINST_ROOT environment variable's
definition has changed, then I could imagine that there might not be a
/home/mcidas/tcl/bin directory.

At this point, I would do the following to rebuild the Tcl/Tk portion of
the distribution:

cd mcidas7.6/src
rm tclcomp
cd ../tcl/unix
make distclean
cd ../../tk/unix
make distclean
cd ../../src
make

This will force Tcl/Tk to be rebuilt.  After the make finishes, a retry
of 'make install' should be done.

BTW, I am willing to login to this machine to plow through this problem
if you want me to.

>I've also made the full makelog available at:
>
>     ftp://ftp.cs.unca.edu/pub/benites/makelog

OK, the Tcl/Tk build doesn't get logged to makelog, so this wouldn't help
in this instance.

>Thanks!

Sorry for the problems...

>From address@hidden Thu Sep 14 13:12:15 2000

>Tom and Bob,

>Since our new faculty, Dr. Leigh Orf is very good at Red Hat, and Unidata
>knows Red Hat as well.  Why don't we replace all McIDAS-X slackware UNIX to
>Red Hat UNIX?

>Is it a good idea or I am asking more troubles?

Well, this makes sense to me, but, then again, I don't have to do the
installation :-)

>Thanks,
>Alex

Tom

>From address@hidden Thu Sep 14 14:16:34 2000
>Subject: [address@hidden: Re: 20000914: 20000914: compile error on Linux for 
>McIDAS-X]

Tom,

Sorry I meant to CC you with this message...

-- bb
------- Start of forwarded message -------
Date: Thu, 14 Sep 2000 16:14:59 -0400 (EDT)
From: Robert Benites <address@hidden>
To: address@hidden
Subject: Re: 20000914: 20000914: compile error on Linux for McIDAS-X

> Since our new faculty, Dr. Leigh Orf is very good at Red Hat, and
> Unidata knows Red Hat as well. Why don't we replace all McIDAS-X
> slackware UNIX to Red Hat UNIX?
>
> Is it a good idea or I am asking more troubles?

Alex, 

Funny you should mention this. I was talking about something like this
with Leigh just a short time ago. I got the impression that Leigh
thinks this kind of upgrade is extremely desireable and we talked
about doing it.

I'm up for the task and I think that Leigh and I could undertake this
and have it done in short order.

However, what with his current busy schedule and course development he
felt he did not have the time, right now, to give this particular
project the proper attention.

Perhaps we could continue with our existing installations and think
about doing this during the holiday break say in December or January?

- -- bb
------- End of forwarded message -------

>From address@hidden Fri Sep 15 06:35:47 2000
>Subject: Re: 20000914: 20000914: 20000914: compile error on Linux for McIDAS-X

> This will force Tcl/Tk to be rebuilt. After the make finishes, a
> retry of 'make install' should be done.

That did the trick. Thanks! :-)

> BTW, I am willing to login to this machine to plow through this
> problem if you want me to.

Thanks, but just having access to your suggestions is really
helpful. Right now we are in a transitional period, what with Jim
gone, Alex taking on more reponsibility and Leigh in the wings. I
really appreciate your offer of help, it's most generous of you, but
I'd rather try to take care of these smaller (?) problems and learn
more in the process. Leigh and Alex will assume more responsibility as
time permits...

Again, thanks for all your help! 

> Sorry for the problems...

No reason to be sorry, we have to expect some problems since we are
running an older version of Linux. We'll upgrade soon so at least you
won't have to answer questions related to outdated versions of Linux.

> Well, this makes sense to me, but, then again, I don't have to do
> the installation :-)

As I said in this transitional period, we'll just plod along and then
when Leigh has more time -- on break, etc. -- we'll upgrade all the
machines to a more recent version of Linux.

Thanks again!

-- bb