Okay, the OSX compiler is a great way to find problems....[this is a long
one - please read]
Brad was building KAPPA and found that all the uses of NUM_ERROR (from
primdat) are problematic because, of course, it sits in a PRM common block
that is completely inaccessible to other libraries when dynamic loading is
in use.
I've done the following:
1. Added 3 new routines to PRM:
NUM_CLEARERR == NUM_ERROR = SAI__OK
NUM_GETERR == STATUS = NUM_ERROR
NUM_WASOK == NUM_ERROR .EQ. SAI__OK
These seem to be the 3 usages in the source code.
I've upped the version number of PRM
NUM_CMN is no longer installed.
2. I've fixed kaplibs to use the above routines. There were only 4 real
routines but they were 20 fortran files. I turned them back into the
original generic routines and fixed the NUM_ERROR problems.
I was more than a little annoyed to discover that CCDPACK ships
with the actual .gen files whereas kaplibs didn't. I wasted a lot
of time with that one doing it manually rather than simply copying
them from ccdpack.
Q1: Can I "fix" ccdpack such that it links against kaplibs directly?
3. I've looked through the rest of the tree for NUM_CMN use.
CCDPACK
CONVERT [only one routines that doesn't actually use NUM_CMN][*]
KAPPA [ccdpack routines]
POLPACK [ccdpack routines]
Fundamentally, everything's CCDPACK. I haven't fixed up ccdpack yet
so it doesn't work with shared libraries yet.
Q2: Can we simply install libccdpack so that kappa and polpack
can just use that? [a ccdlibs package?]
There is one further problem with KAPLIBS. David, kpg1_asira.f
requires access to the IRA_COM common block. Any ideas how to fix that?
It uses 4 variables and it *seems* to only retrieve the variables.
This indicates that 4 accessor functions in IRA would fix things.
[*] It's con_ssazx which is a gratuitous rename of kpg1_ssazx to
hide from me :-) Even more amusing since it includes the .gen
file but kaplibs is missing the .gen file! [**]
[**] I think the source code statistics for Starlink classic are a lie.
Surely 30% of the code is duplicated :-)
Finally, I've started looking at the remaining kaplibs .gen files in
ccpdack. kpg1_ainb is different in ccdpack and kaplibs:
* due to rounding), where the average slope is used to interpolate
* rather than the difference in axis values.
IF ( RESID / SLOPE .LT. 0.0D0 ) THEN
- UB = MAX( LBND, MIN( CINDEX + 1, UBND ) )
+ UB = MAX( LBND + 1, MIN( CINDEX + 1, UBND ) )
DIFF = NUM_RTOD( AXIS( UB - 1 ) - AXIS( UB ) )
IF ( ABS( DIFF ) .LT. NUM_RTOD( VAL__EPSR ) ) THEN
DIFF = SLOPE
@@ -464,7 +463,7 @@
* due to rounding), where the average slope is used to interpolate
* rather than the difference in axis values.
ELSE
- LB = MIN( UBND, MAX( CINDEX, LBND ) )
+ LB = MIN( UBND - 1, MAX( CINDEX, LBND ) )
DIFF = NUM_RTOD( AXIS( LB + 1 ) - AXIS( LB ) )
IF ( ABS( DIFF ) .LT. NUM_RTOD( VAL__EPSR ) ) THEN
DIFF = SLOPE
+ = kappa
- = ccdpack
Note that there is no history difference indicating the edit. I was
wondering which of these variatns is meant to be correct.
Additionally, kpg1_tdlii.f has a bug fix in CCDPACK by Mark that has not
been propagated back to the kaplibs version!
I'll manually generic-ify the kaplibs versions and then send the generic
diffs round between the ccdpack and kaplibs versions for comment.
Fundamentally, I think a lightweight method of linking kaplibs is required
such that only the required libraries are used rather than all of them.
It might be necessary to break libkpg into smaller chunks such that core
routines with minimal external dependencies are separate from those that
require Tk or libira. Then I think the resistance to using kaplibs will
vanish.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|