I'm out for the rest of the week so here are a couple of things that I
want to throw in before I go:
- is there any way that alink can link using the fortran compiler
rather than the C compiler? Is this a problem with linking the
C runtime library? The hard-wired FCLIBS cause problems when
people change g77 version after they have installed the software.
Alternatively, can the path returned from g77 be normalised such that
-L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../..
becomes simply -L/usr/lib ? :-)
- I don't think ast_link is correct at the moment - it seems to think
that ems is a Fortran library when in fact it's pure C. I don't think
it should set f77 to true in that case.
- ARD on 64bit: the %LOC problem. It occurs to me that the real
difficulty with a CNF_PREG function for registering arbitrary pointers
with CNF is that CNF tries to be really clever and tries to make sure
the the lower 32bits of the pointer are unique. Surely this is
unimportant. Yes, if sizeof(Cpointer)==sizeof(Finteger) then it is
important that pointers generated by NDF_MAP and PSX_CALLOC are
"real" pointers and not aribtrary numbers (else "legacy" code that
does not use CNF_PVAL will simply fail immediately). The problem
is that when Fortran integer and C pointer are of different sizes
it's all a bit irrelevant what CNF does with the pointer to integer
mapping so long as CNF_PVAL returns the correct thing. Code that
uses %VAL but no CNF_PVAL will still work on 32bit systems and (as
in the alpha case) where the deep juju linker options are used
to make sure that low 32bits are always okay.
Anyway, what this ramlbing is trying to say is that in the two
cases when:
a) We are registering %LOC pointers with CNF using CNF_PREG
b) sizeof(Cpointer) != sizeof(Fpointer) [and no deep juju link
options]
CNF will be perfectly within its rights simply to store the
C pointers in a lookup table with a monotonically increasing
index. Currently if you forget to use CNF_PVAL in 64bit code
you get a core dump. Making CNF return "1" for the first pointer
and "2" for the second will still give core dumps without CNF_PVAL
(no change there) but guarantees that ALL pointers can be
registered.
What I'm proposing then is that CNF will check
sizeof(void*) != sizeof(F77_POINTER_TYPE) and change it's indexing
scheme to be guaranteed to work [the current scheme always works fine
if the pointer == integer]. The only real issue is the alpha where
in general void* != integer but the current scheme still works
due to linker cleverness (meaning that legacy code using %VAL on
those systems works without CNF_PVAL). As a migratory step we could
engineer things such that CNF will first try to register a pointer
using the current scheme, and fallback to monotonic index scheme
if that fails. [the register code could have a new flag argument
indicating whether this fallback should happen such that psx_
can do it's memory reallocation if needs be].
Comments welcome. It's not clear I have the C skills to modify CNF
safely but it seems to me that this is the easiest way to get the
64bit port working without peppering the code with that INTEGER*8 hack
of Norman's :-)
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|