There can be only one: LAPACK and F2C vs G77 on the Alpha
Package: lapack
Version: 2.0.1-2.1
Package: f2c
Version: 19971204-5
Package: g77
Version: 1:2.91.60-5
We are compiling some C code that uses lapack and blas.
Therefore we used
LOADLIBES=-lblas -llapack -lm
That gave errors
...
/usr/bin/../lib/libblas.so: undefined reference to `e_wsfe'
/usr/bin/../lib/libblas.so: undefined reference to `z_abs'
/usr/bin/../lib/liblapack.so: undefined reference to `c_sqrt'
...
which can be fixed in two ways, either
LOADLIBES=-lblas -llapack -lf2c -lm
or use "g77" instead of "gcc" as the front end to the linker, thus
implicitly linking with /usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/libg2c.a
Both of these succeed and give no error messages, but there's a big
big hidden problem!
/usr/include/f2c.h defines integer as a long int, which on an alpha is
64 bits. g77 uses 32 bits for an integer, on both i386 and Alpha.
One presumes that /usr/lib/lapack.so and friends are compiled with one
or the other, so one of the above ways to link will actually generate
a good executable on the Alpha. Unfortunately the way to figure out
which one is rather unpleasant.
To look at the big picture: g77 and f2c/fort77 produce mutually
incompatible executables on the Alpha, due to their having different
notions of how big an integer is. /usr/lib/libf2c.so.2.1 is not
linked to dynamically under normal circumstances, instead it is
statically linked in (see below for a script showing this - it does
the same thing on both i386 and Alpha.) Similarly g77 doesn't produce
executables dynamically linked to some libg2c.so.
As a result, libraries compiled out of Fortran files are mute on the
issue of which world they live in: the F2C world or the G77 world.
There are a few possible fixes. As a first measure, the Debian Alpha
team should declare whether f2c/fort77 or g77 is the "official"
Fortran compiler for the Alpha, and libraries like lapack should
declare appropriate dependencies to make sure the right one is
installed, and to give users an extra hint about the matter.
As a second measure, both fort77 and g77 and "gcc -l f2c" should
produce executables that dynamically link in an libf2c.so or
libg2c.so, respectively.
As a longer-term measure, probably f2c should be modified to use
32-bit integers, so that gcc, g77, g++, and f2c/fort77 would share the
same notion of the default machine integer size. This would
necessitate recompiling lapack, and would also be a good time to split
f2c up into libf2c, libf2c-dev, and f2c proper.
----------------------------------------------------------------
$ make LDFLAGS='-v -Xlinker --trace'
cc -v -Xlinker --trace cntxtica.o normmix-em.o simath1.o matf.o recipies.o dgesvd.o logdetfgh.o read.o -lblas -llapack -lf2c -lm -o cntxtica
Reading specs from /usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/specs
gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)
/usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/collect2 -m elf64alpha -O1 -dynamic-linker /lib/ld-linux.so.2 -o cntxtica /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/crtbegin.o -L/usr/lib/gcc-lib/alpha-linux/egcs-2.91.60 --trace cntxtica.o normmix-em.o simath1.o matf.o recipies.o dgesvd.o logdetfgh.o read.o -lblas -llapack -lf2c -lm -lgcc -lc -lgcc /usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/crtend.o /usr/lib/crtn.o
/usr/bin/ld: mode elf64alpha
/usr/lib/crt1.o
/usr/lib/crti.o
/usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/crtbegin.o
cntxtica.o
normmix-em.o
simath1.o
matf.o
recipies.o
dgesvd.o
logdetfgh.o
read.o
-lblas (/usr/bin/../lib/libblas.so)
-llapack (/usr/bin/../lib/liblapack.so)
(/usr/bin/../lib/libf2c.a)c_abs.o
(/usr/bin/../lib/libf2c.a)c_div.o
(/usr/bin/../lib/libf2c.a)c_exp.o
(/usr/bin/../lib/libf2c.a)c_sqrt.o
(/usr/bin/../lib/libf2c.a)cabs.o
(/usr/bin/../lib/libf2c.a)d_lg10.o
(/usr/bin/../lib/libf2c.a)pow_dd.o
(/usr/bin/../lib/libf2c.a)r_lg10.o
(/usr/bin/../lib/libf2c.a)s_cat.o
(/usr/bin/../lib/libf2c.a)s_cmp.o
(/usr/bin/../lib/libf2c.a)s_copy.o
(/usr/bin/../lib/libf2c.a)s_stop.o
(/usr/bin/../lib/libf2c.a)sig_die.o
(/usr/bin/../lib/libf2c.a)z_abs.o
(/usr/bin/../lib/libf2c.a)z_div.o
(/usr/bin/../lib/libf2c.a)z_exp.o
(/usr/bin/../lib/libf2c.a)z_sqrt.o
(/usr/bin/../lib/libf2c.a)close.o
(/usr/bin/../lib/libf2c.a)endfile.o
(/usr/bin/../lib/libf2c.a)err.o
(/usr/bin/../lib/libf2c.a)fmt.o
(/usr/bin/../lib/libf2c.a)open.o
(/usr/bin/../lib/libf2c.a)sfe.o
(/usr/bin/../lib/libf2c.a)util.o
(/usr/bin/../lib/libf2c.a)wsfe.o
(/usr/bin/../lib/libf2c.a)F77_aloc.o
(/usr/bin/../lib/libf2c.a)exit_.o
(/usr/bin/../lib/libf2c.a)wrtfmt.o
(/usr/bin/../lib/libf2c.a)fmtlib.o
(/usr/bin/../lib/libf2c.a)wref.o
-lm (/usr/bin/../lib/libm.so)
/lib/libc.so.6.1
/usr/lib/gcc-lib/alpha-linux/egcs-2.91.60/crtend.o
/usr/lib/crtn.o
$ ldd cntxtica
libblas.so.2 => /usr/lib/libblas.so.2 (0x0000020000004000)
liblapack.so.2 => /usr/lib/liblapack.so.2 (0x000002000016a000)
libm.so.6.1 => /lib/libm.so.6.1 (0x000002000069a000)
libc.so.6.1 => /lib/libc.so.6.1 (0x00000200007c6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020001000000)
Reply to: