>From: Anthony James Wimmers <address@hidden>
>Organization: UVa
>Keywords: 199901271455.HAA12002 McIDAS user code
Jennie,
re: RT code
>I agree that I am inclined to try to make this stuff work with
>our version of McIDAS. I was suprised by the response I got
>from Tim S., basically it sounds like they have avoided resolving
>these types of differences.
They obviously modified some "core" routines to do the things that
they wanted and then use the modified routines instead of the core
ones.
>I am inclined to take this approach,
>in part because as in the case I annotated to you and Tony, there
>is at least one examply of including Subroutines in their code that
>duplicate routines in the standard mcidas libraries, but its the
>standard libraries that look more "up-to-date" to me (that is,
>the mcidas library routine makes use of double precision, etc.)
What is up-to-date is not known to me since I don't know what Tim
is trying to do.
>Anyway, the starting point will be to try to resolve the
>overlap.....but, I am writing to get you to update your
>advice, after seeing Tim's input below. I feel reluctant to
>follow the path he suggests, what do you say?
There is another path of lesser resistence. You could rename the entry
points that they modified so that there is no name conflict in the
McIDAS library. This would get you out of the jamb with regards to the
name clash between his routines and the ones in core McIDAS. What it
doesn't do, however, is solve the problem of the duplicate entry point
in their own code:
ld: fatal: symbol `refatm_' is multiply defined:
(file wfgimnt.o type=OBJT; file ./libmcidas.a(trangx.o) type=FUNC);
You will have to resolve this conflict to find out which of his
routines is needed for each of the program executables.
>Thanks again for your input on this.
If you decide to rename the entry points, I would suggest using the
following technique:
sgraoy -> uvasgraoy
interx -> uvainterx
sgraox -> uvasgraox
csraoz -> uvacsraoz
heapfx -> uvaheapfx
I can't advise you on what to do about the multiple definition of
refatm (in wfgimnt.pgm (?) and trangx.for) since I have never seen
the code.
>Jennie
>On Jan 29, 12:11, Tim Schmit wrote:
>> Subject: Re: Compiling
>> Hello. I was wondering when the email about the forward model code would
>> come. (And I never thought it would just say "Thanks for the code, it
>> compiling and is working perfectly".)
>>
>> My comments/questions:
>>
>> 1) What version of mcidas are you running? (not that it really matters).
>>
>> 2) It looks to us like you are trying to compile this code right along with
>> the core mcidas code (libmcidas.a). What we do (and I think you should) is
>> compile the code as another user (for example mclocal).
>>
>> 3) We look first at our local routines (libgops.a) before ever looking into
>> the core mcidas library.
>>
>> 4) You will have to 'clean out' your libmcidas.a directory. The easiest way
>> may be to re-install mcidas. (Or shoot the user modules with 'ar').
>>
>> 5) I may want to turn on the -bmap:name.out option when compiling.
>> We did this and put the results out in the /pub/wf directory (wfgimnt.out).
>
>>
>> 6) I didn't know some of our user subroutines were also in core -- someday
>> we should clean that up!
>>
>> 7) Good Luck.
>>
>> Tim
Tom
--
+-----------------------------------------------------------------------------+
* Tom Yoksas UCAR Unidata Program *
* (303) 497-8642 (last resort) P.O. Box 3000 *
* address@hidden Boulder, CO 80307 *
* Unidata WWW Service http://www.unidata.ucar.edu/*
+-----------------------------------------------------------------------------+
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.