Odd errors when linking statically.
There are multiple definitions of some symbols (e.g. xerbla_)
and some that apparently have different sizes in lapack and blas
(though I confess not to understand what the error really means).

 g++ -v -static  -o oxistem oxistem_main.o oxistem_read.o oxistem.o oxistem_helpers.o ns3.o gstem_fcn.o polys.o target_fcns.o dgels.o -lgpk -llapack -lblas -lm
 Using built-in specs.
 Target: i486-linux-gnu
 Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu
 Thread model: posix
 gcc version 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)
  /usr/lib/gcc/i486-linux-gnu/4.0.3/collect2 -m elf_i386 -static -o oxistem /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.0.3/crtbeginT.o -L/usr/lib/gcc/i486-linux-gnu/4.0.3 -L/usr/lib/gcc/i486-linux-gnu/4.0.3 -L/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib -L/usr/lib/gcc/i486-linux-gnu/4.0.3/../../.. -L/lib/../lib -L/usr/lib/../lib oxistem_main.o oxistem_read.o oxistem.o oxistem_helpers.o ns3.o gstem_fcn.o polys.o target_fcns.o dgels.o -lgpk -llapack -lblas -lstdc++ -lm --start-group -lgcc -lgcc_eh -lc --end-group /usr/lib/gcc/i486-linux-gnu/4.0.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crtn.o
  /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/libblas.a(xerbla.o): In function `xerbla_': multiple definition of `xerbla_'
  /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/liblapack.a(xerbla.o): first defined here
  /usr/bin/ld: Warning: size of symbol `xerbla_' changed from 97 in /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/liblapack.a(xerbla.o) to 57 in /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/libblas.a(xerbla.o)
  /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/liblapack.a(dormlq.o): In function `dormlq_': undefined reference to `s_cat'
  /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/liblapack.a(dormlq.o): In function `dormlq_': undefined reference to `s_cat'
  /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/liblapack.a(dormqr.o): In function `dormqr_': undefined reference to `s_cat'

I should add that those errors did not appear when I linked
without the -static flag.   In the dynamic case, the program
linked and ran without trouble.

Hi,

I can confirm #354463 is still the case with refblas3-dev 1.2-8 and
lapack3-dev 3.0.20000531a-6 on Debian "sid".  This bug in some cases
causes static linking of binaries against liblapack.a to fail.

best regards,

A small work around if someone is stumped by this bug.

I found out that using libraries under /usr/lib/atlas fixes the
problem. For example, instead of statically linking against
/usr/lib/liblapack.a, /usr/lib/libblas.a , use
/usr/lib/atlas/liblapack.a /usr/lib/atlas/libblas.a respectively.

raju

This is definitely a bug in Debian's LAPACK.


$ nm /usr/lib/libblas/libblas.a | grep xerbla_
0000000000000000 T xerbla_

shows that the symbol xerbla_ is defined the static BLAS library.
Additionally,

$ nm /usr/lib/liblapack.a | grep xerbla_
[...]
0000000000000000 T xerbla_

it is defined in  /usr/lib/liblapack.a. This causes link errors whenever
LAPACK, BLAS are used statically.

/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libblas.a(xerbla.o): In
function `xerbla_':
(.text+0x0): multiple definition of `xerbla_'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/liblapack.a(xerbla.o):(.text+0x0):
first defined here

Hi,

this actually seems like an upstream problem. netlib adds xerbla.f to
the lapack library, but xerbla is already supposed to be in blas
itself.

The attached patch fixes the problem on my system (Debian
wheezy), by simply not putting xerbla.f into lapack. Please double
check and feel free to forward it upstream.


Cheers,

Markus