>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
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.