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

19990206: building site developed code to Unidata McIDAS (cont.)

>From: Anthony James Wimmers <address@hidden>
>Organization: UVa
>Keywords: 199901271455.HAA12002 McIDAS user code


>Here's the deal: I thought I cleaned up the radiative transfer package, but 
>since it didn't compile right today, I must have tripped up somewhere along
>the line. Let me show you the error message, then I'll run down what I've
>done since we last corresponded. I think it'll be easy to fix.
>When trying:
>windfall: /home/mcidas/mcidas7.4/src $ make wfgimnt.k,
>the makelog says:
>./mccomp -I. -c wfgimnt.pgm
>fc -c -O wfgimnt.f
>/usr/bin/fc[8]: fc: bad option(s)
>compile        wfgimnt.pgm:            FAILED

The fact that 'fc' is being called tells me that someone there downloaded
the new mcupdate.tar.Z file recently.  It also implies that there is either
an old version of makefile (likely since you are playing with it) and a
new version of 'mccomp' (generated by make from the mccomp.sh template)
or some other unknown problem.  I expect that the problem is that you are
did get the new mcupdate.tar.Z file and have been using an old (pre-latest
update) makefile.  The reason for my conjecture is that the only way that
'mccomp' will try to use 'fc' as the Fortran compiler is if you are using
the new mccomp.

So, what you should do is modify the copy of 'makefile' that you are using
in the and make sure that yours has the following code:

# General macros.

INCARGS         = -I.

STRIP           = -s
# STRIP         =

# DEBUG         = -g
DEBUG           =

# BFC           = -f2c bfc
BFC             =

COMPILERS       = -vendor

The thing that is likely to have changed is the addition of the COMPILERS
macro.  This was added so that we can support use of gcc/f2c on Sun

>and with:
>windfall: /home/mcidas/mcidas7.4/src $ make lisgix.k,
>the makelog says, similarly:
>./mccomp -I. -c lisgix.pgm
>fc -c -O lisgix.f
>/usr/bin/fc[8]: fc: bad option(s)
>compile        lisgix.pgm:             FAILED

This is the same problem as above.

>So, now let's go over some possible errors: 

The error related to 'fc' negates all of the following possible problems.

>1. About two weeks ago, like you said, I removed these files from the
>ar r libmcidas.a rfraox.o
>ar r libmcidas.a upraox.o
>ar r libmcidas.a trangx.o
>2. Between now and then, Owen fixed up the problem with incoming FRONT data, 
>which involved changing some pieces in the makefile. When I looked at it today,
>the additions you wrote about compiling the radiative transfer code were 
>missing. Owen must have used the backup version to make the new version. But I
>did not yet know this about the new makefile.

OK, this pretty much proves that the COMPILERS macro code is not in the
copy of makefile that you are using.

>3. Today (Saturday) I changed the code so that all of the redundant subroutines
>and the redundant data array were renamed to avoid multiple definitions.

OK, good.

>4. Next, I thought (probably wrongly) that since I would be recompiling 
>wfgimnt.pgm and lisgix.pgm, I needed to remove these from the library.

The object code for program files is not put into the library.  Only subroutine
object code is put into the library.

>At the 
>time, I thought that they get put back during compiling. Now I'm not so sure. 
>The commands were:
>windfall: /home/mcidas/mcidas7.4/src $ ar r libmcidas.a wfgimnt.o
>windfall: /home/mcidas/mcidas7.4/src $ ar r libmcidas.a lisgix.o
>Probably not a good idea.

Since wfgimnt.o and lisgix.o were probably not in the library, this wouldn't
do anyting.

>5. I tried compiling wfgimnt, which obviously didn't work because the makefile
>didn't have the code you wrote for us anymore. When I found this out, I put
>your code back in, in the same place. (I've included this code at the end of
>the message, in case you don't have a copy of that message anymore.)

The question is whether or not the version of makefile that you are using
has the COMPILERS macro code?

>6. I tried again to compile wfgimnt and lisgix, which generated the following 
>./mccomp -I. -c wfgimnt.pgm
>fc -c -O wfgimnt.f
>/usr/bin/fc[8]: fc: bad option(s)
>compile        wfgimnt.pgm:            FAILED
>./mccomp -I. -c lisgix.pgm
>fc -c -O lisgix.f
>/usr/bin/fc[8]: fc: bad option(s)
>compile        lisgix.pgm:             FAILED

Same problem as above.  With COMPILERS set to -vendor, and with the new
version of 'mccomp' (generated by you by running 'make mccomp'), the compilation
lines would look like:

f77 -c -O wfgimnt.f


f77 -c -O lisgix.f

>...as I mentioned earlier. I'm not very good with unix fortran compilers, so I
>don't understand the message. Regardless, I do need to know if anything I 
>mentioned in this email was a bad move.

The fix should be very easy.  Simply edit ~mcidas/mcidas7.4/src/makefile
and add the COMPILERS macro code exactly as I listed above.  Then
insure that you have a new copy of 'mccomp' by running 'make mccomp'.
After that, you should do:

rm wfgimnt.o lisgix.o
make wfgimnt.k lisgix.k

>Thanks a bundle,

Let me know if you run into problems.


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.