Re: There can be only one: LAPACK and F2C vs G77 on the Alpha
On Wed, 17 Feb 1999, Barak Pearlmutter wrote:
> Yes it is, but *statically* linked, as there is no libg2c.so.*.
> gcc -lf2c similarly *statically* links in libf2c (yes, even though
> libf2c.so.x is available.) If you make a symbolic link
> /usr/lib/libf2c.so -> libf2c.so.2 to force the issue, there's a
> link-time error when the dynamic link is attempted.
Forgive me here, but why would you want to link it dynamically? Given the
contents of libf2c and libg2c, it wouldn't make a whole lot of sense to
dynamically link to either (maybe it's me...I'm kinda ill today, so
don't think I'm being insulting).
> The required mods are actually mentioned in /usr/doc/f2c/readme, where
> it recommends taking out some "long"s on 64-bit long int machines, and
> even gives a sed command to do it.
> Glancing at /usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/include/g2c.h
> and /usr/include/f2c.h shows that the long-removal mods are already
> done to g2c.h on the Alpha, but not on i386.
Right. Alignments are different, as are the sizes of each respective data
type (ok, I'll agree that they REALLY don't differ on new processors in
the x86 family, but egcs ignores that and opts for backward compat, unless
told otherwise).
The best approach is to modify the f2c package to behave properly on all
archs (a series of #ifdef's to isolate the differences should do it) and
contact the maintainer with diffs that they can include and test with the
next release. I personally think this is a major bug in f2c since f2c is
incorrectly implemented on the Alpha and assumes x86 type sizes apply (for
instance, Alpha has no "long long" type and the size of "long" is
different between the two).
I'm surprised I never caught this before when I was playing with f2c, but
it's understandable since I haven't written in Fortran-77 for about 16
years now :-)
> In some ways, but (to my knowledge) there is no g77 option to make a
> default integer be 64-bit instead of the default default of 32-bit.
No, and never will be. I see now what you're saying. No matter what the
BLAS stuff will have to be recompiled with proper type sizing and
alignment settings. After that, a recompilation by either method
(assuming f2c has been fixed) should produce the same results.
A tip, if you decide to modify f2c yourself (time is limited in my realm,
so I may not get to it quick enough), you may try altering the machdef.h
to use non-hardcoded sizes for the basic types (int, float, etc) and
instead, you could try defining things like this:
#define SZINT sizeof(int)
It might work, but I haven't studied the source intently yet to see if the
proper headers are included before machdef.h to pull this off (easy to fix
also). f2c.h could probably be made more generic using this method as
well...
C
Reply to: