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

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

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

Tony,

>We're halfway there I think. There are two programs, and right now I'm
>trying to build "wfgimnt.k". It compiled every fortran program but one,
>and on that one it pointed out an error on one line. That line had a
>command called "EXIT":
>
>      do i=1,nlr
>          if(pr(i).le.1000.) then
>             lb=i
>            thlwr=pottem(tr(lb),pr(lb))
>             exit
>          endif
>      enddo
>
>So I changed that command to "return" and then it compiled fine. Maybe you
>can question the wisdom of that choice. 

EXIT goes at the end of a main fortran program.  In McIDAS, all "programs"
are actually subroutines.  The "main" function is provided by a standard
preamble that does things like connect to an existing McIDAS session
if it exists (i.e. get access to already allocated User Common) or
create a mini-session if it doesn't.  Your change of exit to return was
the correct action.

>Anyway, with all the object files made, it began linking, and the makelog
>gives me this:
>
>./mccomp -s -o wfgimnt.k main.o wfgimnt.o -L. -lmcidas
>f77 -s -o wfgimnt.k main.o wfgimnt.o -L. -R/usr/dt/lib -L/usr/dt/lib
>-R/usr/openwin/lib -L/usr/openwin/lib -R/opt/SUNWspro/lib
>-L/opt/SUNWspro/lib -lmcidas -lgen -lsocket -lnsl -lm
>ld: fatal: symbol `sgraoy_' is multiply defined:
>       (file ./libmcidas.a(csraox.o) and file ./libmcidas.a(rfraox.o));
>ld: fatal: symbol `interx_' is multiply defined:
>       (file ./libmcidas.a(csraox.o) and file ./libmcidas.a(rfraox.o));
>ld: fatal: symbol `sgraox_' is multiply defined:
>       (file ./libmcidas.a(csraox.o) and file ./libmcidas.a(rfraox.o));
>ld: fatal: symbol `csraoz_' is multiply defined:
>       (file ./libmcidas.a(csraoz.o) and file ./libmcidas.a(rfraox.o));
>ld: fatal: symbol `heapfx_' is multiply defined:
>       (file ./libmcidas.a(csraox.o) and file ./libmcidas.a(rfraox.o));
>ld: fatal: symbol `refatm_' is multiply defined:
>       (file wfgimnt.o type=OBJT; file ./libmcidas.a(trangx.o)
>type=FUNC);
>ld: fatal: symbol `csraoz_' is multiply defined:
>       (file ./libmcidas.a(csraoz.o) and file ./libmcidas.a(upraox.o));
>ld: fatal: File processing errors. No output written to wfgimnt.k
>link   wfgimnt.k:              FAILED

This is the caution that I included in my earlier note.  There can be
only one entry point of a particular name in a library.  If any
of the routines that you were adding to the McIDAS library had the
same entry point names as on others in the library, then you will get
a link failure.  I was hoping that this would not be the case, but
it obviously is.

>So I checked this pesky "rfraox.for" program,

Set of subroutines, not a program.

>and found that all of those
>problematic symbols are declared as "entry"'s. For example:
>
>      ENTRY SGRAOY(IDNO,NSIGT,NSIGW,ISND)
>
>I don't know what ENTRY's are,

ENTRY points in a Fortran subroutine are a way of accessing code
in the routine without going through the top level calling sequence.
This is standard Fortran, it is not a problem.

>and I have a hunch that the f77 compiler
>doesn't handle them correctly. Am I right?

No, what is happening is that the rfraox.for routine is defining the
various entry points internally (through ENTRYs).  The entry points are
defined in other routines.  You can see from the listing that the entry
points sgraoy, interx, sgraox, and heapfx are all defined in
csraox.for; csraoz is defined in csraoz.for; and refratm is defined in
trangx.o.

csraox.for and csraoz.for are part of the standard SSEC McIDAS
distribution.  We don't want to mess with them.  trangx.o is the object
file created when trangx.for is compiled, and upraox.o is the object
file created when upraox.for is compiled.  These are two of the routines
that you had in your list of things you wanted to use in building the
new programs.  The question is why the same entry point is defined
in multiple files that you were given by Tim S?

>I don't know the meaning of the error message, and I need to know whether
>the errors are the result of using the wrong compiler.

The errors are not releated to which compiler is being used, but, rather,
having multiple entry points of the same name in libmcidas.a.

>Any other advice you can give would be helpful too.

Here is what I would do:

o remove rafraox.o, trangx.o, and upraox.o from libmcidas.a:

cd ~mcidas/mcidas7.4/src
ar r libmcidas.a rafraox.o trangx.o upraox.o

o find out _why_ rfraox.for is redefining all of the entry points
  from csraox.for and csraoz.for
o find out if the code defining the refatm entry is duplicated in
  wfgimnt.pgm and trangx.o
o find out why rfraox.for AND upraox.for are both defining the csraoz
  entry point

"find out" means that you will have to do comparisons between the
routines in csraox.for and csraoz.for and those in rfraox.for,
upraox.for, and wfgimnt.pgm.  It is possible that the codes are the
same in which case you could remove adding rfraox.o and trangx.o to
libmcidas.a (this will mean editing the 'makefile' snippit I sent you
earlier and adjusting your current version of 'makefile'.

It might be a good idea to bounce back to Tim and ask him if he can
provide you with an idea for why there are redefinitions of standard
McIDAS routines.  He probably has a good reason, but it would be
interesting to hear what it is.

>Thanks,

If you can't make any headway, I could take a quick look to see if
I could understand the need for the entry point redefinitions and
make sense out of them.

Tom

>From address@hidden  Wed Jan 27 19:44:48 1999

Tom (and Tony) we will have to go back to Tim.  I just took a look
at the file upraox.for for example, and included in it is the subroutine
csraoz, as Tom noted, we already had this subroutine, *but* its not
identicle code.  In particular, what stands out is that csraoz.for
includes double precision definitions of several variables...the
subroutine csraoz included with upraox.for does not include these definitions. 
Water vapor mixing ratios are being calculated within csraoz, but in the code
Tim sent us as part of uproax.for, the mixing ratios are retrieved
from the subroutine RMIX (passing dewpoint and pressure), however
the mixing ratios from the mcidas routine csraox.for gets mixing
ratios from mcrmix(double precision dewpoint, double precision pressure).

So, I think we need to go to Tim to figure this out.

Tony, lets discuss it tomorrow.

Thanks again Tom.

Jennie