Folks (but especially Mark),
I've had second thoughts about the modifications I made to ccdwish.c
yesterday, concerned with initialising the variables used by Fortran
getarg(). I've rewritten the main function in ccdwish.c so that it has
the name of the function which is called by the Fortran RTL (namely
MAIN__ in the case of g77). When this is linked against the Fortran
RTL, therefore, that library initialises everything properly, then
calls ccdwish's main function. The downside of this is that there's a
certain amount of faffing around now required in ccdwish.c, to
reassemble a local argv from calls to iargc() and getarg() (it has to
be passed on to Tk_Main). However this will mean that Fortran will be
fully, and properly, initialised. Since we don't use any Fortran I/O,
this is more than we need, but it shouldn't do any harm.
This builds successfully on OSX, and appears to work (in the sense that
it doesn't crash when I run up ccdwish) -- we'll see what happens in
the build tonight. Though I don't think that the STAR_FC_SETARG macro
was necessarily hacky, it seems wise to me to use well-battered
autoconf macros, and avoid being so trigger-happy adding my own.
I think this _should_ be OK, but if problems arise or can be predicted,
we can either revert to the earlier method, or think of something
cleverer.
Something along the same lines needs to happen with dipso, which has
the same f__xargv linking problems as ccdwish had, but it's a little
more complicated there. run_dipso.c already does something like this
(written to be run from the Fortran RTL main), but it's not _quite_ as
simple, since there's some extra signal-handling magic in there. It's
probably OK, and replacing the current platform-specific special-casing
with FC_MAIN might actually tidy it up somewhat, but I don't want to do
it in a hurry.
ccdwish is currently linked using the C compiler and FCFLAGS. It could
probably more reasonably be linked with $FC. If folk agree, I can
arrange that neatly, by merging in some automake stuff that's currently
nestling on a branch, but again I don't want to do that in a hurry
before leaving tomorrow.
I don't think we're quite out of the OSX woods yet, however. I was
thinking about the issue of the paths in FCFLAGS, and them being
specific to a compiler version (Tim raised this a while ago, Brad
mentioned it earlier today, and I've been chatting with DSB about it).
I'm not sure what's going on here, but it might be indicating a quite
general OSX distribution/packaging problem. Tomorrow's headache....
See you,
Norman
--
----------------------------------------------------------------------
Norman Gray : Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
|