ScaLapack linking problem, undefined reference to `dpttrf_'

[mikael]

I am becoming desperate with the following linking problem:

I try to compile a piece of testing code 'pdp.c'. The problem comes from the ScaLAPACK functions pdpttrs and pdpttrf (or more precisely, their c-counterparts with _).
The compiler appears to find them, but still gives an error:

/home/mikael/Libs/scalapack-2.0.2//libscalapack.a(pdpttrf.o): In function `pdpttrf_':
pdpttrf.f:(.text+0x4b4): undefined reference to `dpttrf_'

I am probably not linking everything necessary, but what am I missing? My compilation mantra looks like this:

mpicc -o pdp pdp.c -I/home/mikael/Libs/lapack-3.5.0/lapacke/ -L/home/mikael/Libs/lapack-3.5.0/ -llapacke -llapack -I/home/mikael/Libs/scalapack-2.0.2/ -L/home/mikael/Libs/scalapack-2.0.2/ -lscalapack -lblas -lgfortran -lm

[admin]

Michael,
Try changing the order of the libraries : ScaLAPACK first, then LAPACKE, then LAPACK then BLAS then GFORTRAN, then LM

The DPTTRF routine is part of LAPACK. So that means ScaLAPACK cannot find LAPACK

Another reason could be a mangling error (linking from C to Fortran) - but I would doubt it.
When you run the ScaLAPACK installer, it will let you know which mangling we used (most of the time it is adding _ ( -DAdd_) , like you did, but this depends on the machine and compilers.

If you are struggling too much, please let us know what machine and compiler your are using, and send us your testing code. We should be able to provide you the correct linking sequence.
Good luck.
Julie

[mikael]

Thanks, changing the linking order seems to work!
For matter of understanding, could you explain why it is so important to get the linking order right?

[Julien Langou]

Hi Mikael,
Order matters, please have a look at stack overflow: http://stackoverflow.com/questions/45135/linker-order-gcc I think the article is pretty good.

Code: Select all

+- prog.o -----+   +- libA.a -----+   +- libB.a -----+   
|   U funcA  --|---|-> T funcA    |   |              |    U : undefined/used
|              |   |   U funcB  --|---|-> T funcB    |    T : defined
|   T main     |   |              |   |              |   
+--------------+   +--------------+   +--------------+


The correct way to link is:

Code: Select all

gcc prog.o libA.a libB.a -o prog.x

If you have libB.a before libA.a,

Code: Select all

gcc prog.o libA.a libB.a -o prog.x

first, the linker (gcc in this case) considers libB.a, it looks for all it needs in libB.a, that is it looks for all undefined functions it knows of in libB.a, so it looks for funcA in libB.a, funcA is not in libB.a, so the compiler proceeds to the next library: libA.a, there it looks for all undefined functions it knows of in libA.a, so it looks for funcA in libA.a, it finds it (yeah!), but now we see that funcA needs funcB, so the list of undefined functions grows by one entries: funcB. Then the compiler proceeds to the next library: there is nothing after libA.a, so it is left with an undefined funcB.

Julien.