CP2K compilation errors

[Eric Shamay]

The final compilation of all the libraries went through just fine.
I've managed to get the linking process down in the arch (popt) file
to the point where I'm only getting reference errors from scalapack
(they look like the following):

/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pdlase2.o)(.text
+0x1b00): In function `pdlase2_':
: undefined reference to `dlaset_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pzlarfb.o)(.text
+0x5440): In function `pzlarfb_':
: undefined reference to `zlacpy_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pzlarfb.o)(.text
+0x5460): In function `pzlarfb_':
: undefined reference to `zlaset_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pzlarft.o)(.text
+0x3b80): In function `pzlarft_':
: undefined reference to `zlaset_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pzlarft.o)(.text
+0x3ba0): In function `pzlarft_':
: undefined reference to `zlacgv_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pdlarfb.o)(.text
+0x5140): In function `pdlarfb_':
: undefined reference to `dlacpy_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pdlarfb.o)(.text
+0x5160): In function `pdlarfb_':
: undefined reference to `dlaset_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pdlarft.o)(.text
+0x3600): In function `pdlarft_':
: undefined reference to `dlaset_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pzlarf.o)(.text
+0x39c0): In function `pzlarf_':
: undefined reference to `zlaset_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pzlarfc.o)(.text
+0x39c0): In function `pzlarfc_':
: undefined reference to `zlaset_'
/home/users/eshamay/tmp/SCALAPACK/libscalapack.a(pdlarf.o)(.text
+0x3780): In function `pdlarf_':
: undefined reference to `dlaset_'

I can't find any info on the dlaset_, zlaset_, etc. functions, or what
library I need to link to in addition. Also, I want to note for future
compilers the linking order I came up with, so below is my updated
popt file:

########################################################3
# using openmpi 1.2
#       ATLAS 3.6.0
#       mpiBLACS 1.1 with patch03
#       scalapack 1.8.0
#
PERL     = perl
CC       = mpicc
CPP      = cpp
FC       = mpif90 -FR
FC_fixed = mpif90 -FI
LD       = mpif90
AR       = ar -r
###########
# Here are the locations of the newly built libraries
###########
SCALAPACK   = $(HOME)/tmp/SCALAPACK
ATLASLIB    = $(HOME)/tmp/ATLAS/lib/Linux_IA64Itan2_16
BLACSLIB    = $(HOME)/tmp/BLACS/LIB
###########
DFLAGS   = -D__INTEL -D__FFTSG -D__FFTW3 -D__parallel -D__BLACS -
D__SCALAPACK -I$(FFTW)/include
CPPFLAGS = -C $(DFLAGS) -P -traditional
FCFLAGS  = -O2 -Vaxlib -tpp2
LDFLAGS  = $(FCFLAGS) -L$(FFTW)/lib -L$(MPI)/lib -L$(BLACSLIB) -L$
(ATLASLIB) -L$(SCALAPACK)
###########
# These use the home-built libraries
LIBS     = -lscalapack $(BLACSLIB)/blacs_MPI-LINUX-0.a $(BLACSLIB)/
blacsCinit_MPI-LINUX-0.a $(BLACSLIB)/blacsF77init_MPI-LINUX- 0.a $
(BLACSLIB)/blacs_MPI-LINUX-0.a -llapack -lcblas -lf77blas -latlas -
lblas -lg2c -lguide -lmpi -lfftw3
###########

OBJECTS_ARCHITECTURE = machine_intel.o


Note that the call to blacs_MPI-LINUX-0.a happens before and after the
other BLACS library files. Also, the order of the calls to lapack and
blas is important: -llapack -lcblas -lf77blas -latlas -lblas

Anyhow, any help with the undefined reference errors would be greatly
appreciated!
Thanks,
~Eric





On Jun 1, 3:39 pm, akohlmey <akoh... at gmail.com> wrote:
> On Jun 1, 6:17 pm, Eric Shamay <eric.... at gmail.com> wrote:
>
> > The errors do point to BLACS, so I hope this will work. I didn't
> > realize that I'd have to go back in the recompiling-tree and redo each
> > component everytime I update a lower component (in this case, mpi).
>
> the question is always whether that are changes in the binary
> interface, i.e. the ABI. also you have to make sure that your
> configuration is correct.
>
> > Thanks for the heads up, I'll take note of what each was compiled
> > against for records from now on.
>
> > Why is it that cp2k is so touchy with regards to minor version changes
> > in the mpi routines? Do mpi libraries deprecate calls from earlier
> > versions?
>
> the problem is not a problem of cp2k directly (unless you want to
> blame
> cp2k for using a larger subset of the functionality of the underlying
> libraries and language than other packages), but in the fact, that
> openmpi
> uses shared libraries and thus you have to always make sure, that you
> use a set of libraries, that match the definitions of the header/
> include files.
>
> the best strategy is in fact, to always build everything from ground
> up
> until you have a consistent set. it helps to script the build process,
> so that you know what set of flags you were using where.
>
> just mix and matching different libraries can work, but you'd never
> know why something was working (or not).
>
> cp2k _is_ a large and complex package and that shows in the build
> process. however, once you have a working setup, keeping up-to-date
> is rather simple.
>
> cheers,
>    axel.