Hi all,

Sorry I made the big fuss about BLAS crashing. I should no better than
working till 2 in the morning, when I know it takes me 5 minutes to find
the bug in the morning when I am fresh.

The bug is not trivial though, it comes from the fact that I used a
shared version of the BLAS instead of the native static library
distributed by G. Henry. I talked to him about this some time ago, adn
back then I "converted" libblas.a into libblas.so by (silly me)
extracting all the objects from the static lib with Linux ar, and then
repackaging them with:
lf95 -shared -o libblas.so *.o
This worked and I could then use this library for some level 2 and 3
routines without problems.

Later I found out that a good way of converting .a to .so libraries is:
ld --whole-archive -shared libblas.a -o libblas.so
I told this to G. Henry and he even included it in his blas.html
distribution page (Please remove it, since as commented below, it seems
not to work!)
I never tried this with BLAS, since I had packed it earlier. Well, today
I noticed that my crashes with DDOT and DAXPY appeared *only* when using
the shared library. So I tried to repackage the static library and got
lots of errors:

[hpf@gauss hpf-2DNet]$ ld --whole-archive libblas.a -o libBLAS.so
-shared
libblas.a(dgemv2_8x8.o): In function `dgemv288_':
dgemv2_8x8.o(.text+0x0): multiple definition of `dgemv288_'
libblas.a(dgemv2_8x8.o)(.text+0x0): first defined here
libblas.a(dgemv2_mx16.o): In function `dgemv2m16_':
...

So the BLAS as distributed can not be converted into a shared library
without messing things up. More importantly though, after more carefully
reading:
http://dwheeler.com/program-library/ or
http://www.linuxfocus.org/English/November1997/article6.html
I realized that the -fPIC or -shared compilation switch on the compilers
is more important than I though since it generated dynamically allocated
addresses for something...So it is a good guess that libblas.a should
remain as it is until someone fixes it internally to be shared
compatible.
Notice that similar problems don't appear with the LAPACK, since one can
use the -shared switch to generate Position Independent Code.

Now, a question to the Fortran community. The reason I needed a shared
BLAS is that I used the Fortran 95 interface to it, and I packaged all
of it in one module BLAS.f90. The resulting object file from compiling
this module interface containted references to all the routines in the
BLAS, even though it didn't use them, so that when I compiled a Fortran
90 program with USE BLAS it was 2.5 MB large regardless of which
functions I actually used. If one doesn't use the module, than only the
objects for the specific functions that are used are linked.
My question is, what am I to do to find a nice solution to this problem?

Also, when reading the above articles on libraries under Linux it said
that it is bad to package libraries that you use only a small portion of
into shared libraries, since the *whole* library will be loaded into
memory. I didn't know this and it now worries me. I use the MPI library
and the HPF runtime library DALIB in every program. So if I use static
linking, every executable I make will have redundant copies of the same
objects, and thet won't be upgradable. But I also don't want to load the
whole MPICH 10 MB or so into memory each time I run a program. How can I
check to see if this happens?
Anybody have experience with this.

Thanks a lot,
Aleksandar

--
_____________________________________________
Aleksandar Donev
Physics Department
Michigan State University
East Lansing, MI 48824-1116
E-mail: [log in to unmask]
Work phone: (517) 432-6770
_____________________________________________


program test
implicit none
external :: SDOT, SCOPY, SNRM2, SASUM, ISAMAX, SAXPY
real :: SASUM, SDOT, SNRM2, dots
real, allocatable, dimension(:) :: vec1,vec2
integer :: N,indx,ISAMAX
write(*,*) "N?="
read(*,*) N
allocate(vec1(N),vec2(N))
call random_number(vec1)
call random_number(vec2)
write(*,*) vec1, vec2
dots=SDOT(N,vec1,1,vec2,1)
call SAXPY(N,1.0,vec1,1,vec2,1)
write(*,*) vec1, vec2 , dots
end program test
!