> On Mon, Jun 23, 2008 at 9:00 AM, Daniele Bettella <
address@hidden> wrote:
>
> > I'm sending this problem back to getfem-users; the actual error I get is
> > below.
> >
> > /bin/sh ../libtool --tag=CXX --mode=link mpicxx
> > -I/home/bettella/trilfem/trilinos/include -D GETFEM_PARA_LEVEL=2
> > -I/home/bettella/trilfem/mumps/include -O3 -L/home/bettella/trilfem/blacs
> > -lblacs -lblacsF77 -lblacsC -lblacs -lblacsC
> > -L/home/bettella/trilfem/trilinos/lib -lepetra -ltriutils -laztecoo
> > -lteuchos -L/home/bettella/trilfem/metis -lmetis -lparmetis
> > -L/home/bettella/trilfem/scalapack -lscalapack
> > -L/home/bettella/trilfem/mumps/lib -ldmumps -lcmumps -ldmumps -lsmumps
> > -lzmumps -lpord -llapack -o elastostatic elastostatic.o ../src/
> >
libgetfem.la -lm -L/home/bettella/trilfem/mumps/lib -lcmumps -ldmumps
> > -lsmumps -lzmumps -lpord -lblas
> > mpicxx -I/home/bettella/trilfem/trilinos/include -D GETFEM_PARA_LEVEL=2
> > -I/home/bettella/trilfem/mumps/include -O3 -o .libs/elastostatic
> > elastostatic.o -L/home/bettella/trilfem/blacs
> > -L/home/bettella/trilfem/trilinos/lib -L/home/bettella/trilfem/metis
> > -L/home/bettella/trilfem/scalapack -L/home/bettella/trilfem/mumps/lib
> > ../src/.libs/libgetfem -lblacsF77 -lblacs -lblacsC -lepetra -ltriutils
> > -laztecoo -lteuchos -lmetis -lparmetis -lscalapack -llapack
> > /home/bettella/trilfem/openmpi/lib/libmpi_cxx.so
> >
>
-L/usr/local/Gruppi/Marcuzzi/src/Build/gcc-4.1.2-obj/x86_64-unknown-linux-gnu/libstdc++-v3/src
> >
>
-L/usr/local/Gruppi/Marcuzzi/src/Build/gcc-4.1.2-obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
> > -L/usr/local/Gruppi/Marcuzzi/src/Build/gcc-4.1.2-obj/./gcc
> > -L/usr/local/Gruppi/Marcuzzi/lib
> > /home/bettella/trilfem/openmpi/lib/libmpi.so
> > /home/bettella/trilfem/openmpi/lib/libopen-rte.so
> > /home/bettella/trilfem/openmpi/lib/libopen-pal.so
> > /usr/local/Gruppi/Marcuzzi/lib/../lib64/libstdc++.so -lm -lcmumps -ldmumps
> > -lsmumps -lzmumps -lpord -lblas -Wl,--rpath
> > -Wl,/home/bettella/trilfem/getfem/lib -Wl,--rpath
> > -Wl,/home/bettella/trilfem/openmpi/lib -Wl,--rpath
> > -Wl,/usr/local/Gruppi/Marcuzzi/lib/../lib64
> > /home/bettella/trilfem/mumps/lib/libdmumps.a(dmumps_part3.o)(.text+0xbd54):
> > In function `dmumps_270_':
> > : undefined reference to `numroc_'
> >
> >
> > a list of undefined references from both scalapack and blacs (gridinfo etc)
> > foolow; the relevant linked libraries exist and have the functions defined
> > (checked with nm).
> > Any help would be appreciated.
> >
> > Daniele
> >
> >
> >
> > On Wed, Jun 18, 2008 at 6:52 PM, Daniele Bettella <
address@hidden>
> > wrote:
> >
> >> I'm linking with gcc, changing order won't change the error message...
> >>
> >>
> >> On Wed, Jun 18, 2008 at 5:18 PM, Richard George <
address@hidden> wrote:
> >>
> >>> Hi Daniele
> >>>
> >>> I think
> >>>
> >>> U means "this library requires ...."
> >>>
> >>> and
> >>>
> >>> T means "this library provides ...."
> >>>
> >>> so looks like linking against /home/bettella/trilfem/blacs/libblacs.a
> >>> should make it work?
> >>>
> >>> Is the linker sensitive to the order that you specify the libraries?
> >>> some of them only make one pass and they need the libraries specified in
> >>> the right order.
> >>>
> >>>
http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html
> >>>
> >>> eg. if you put -L${BLACSDIR} -lblacs ... as the first argument rather
> >>> than the last one in LDFLAGS, does that change the error message / make
> >>> it work?
> >>>
> >>> Yours
> >>>
> >>> Richard
> >>>
> >>>
> >>> On Wed, 2008-06-18 at 17:01 +0200, Daniele Bettella wrote:
> >>> > Hi and thanks again for your help. I'm creating a bash script that
> >>> > should automatically install getfem, it's dependencies and other
> >>> > stuff, the directories pointed by those variables are the places where
> >>> > I previously installed the libraries (and they are all in a directory
> >>> > tree under /home/bettella/trilfem/). I'm pretty sure all the variables
> >>> > are correct as I've checked them many times on config logs.
> >>> > So I've used your script (nice! thanks!) to search for blacs_gridinit
> >>> > and I get many results, the following are the most interesting:
> >>> >
> >>> > blacs_gridinit_ in blacs_gridinit_.o
> >>> > Cblacs_gridinit in Cblacs_gridinit_.oo
> >>> > blacs_gridinit_.o:
> >>> > 0000000000000000 T blacs_gridinit_
> >>> > Cblacs_gridinit_.oo:
> >>> > 0000000000000000 T Cblacs_gridinit
> >>> > symbol exists in library /home/bettella/trilfem/blacs/libblacs.a
> >>> >
> >>> > U blacs_gridinit_
> >>> > symbol exists in library /home/bettella/trilfem/mumps/lib/libdmumps.a
> >>> > U blacs_gridinit_
> >>> > symbol exists in library /home/bettella/trilfem/mumps/lib/libsmumps.a
> >>> > U blacs_gridinit_
> >>> > symbol exists in library /home/bettella/trilfem/mumps/lib/libcmumps.a
> >>> > U blacs_gridinit_
> >>> > symbol exists in library /home/bettella/trilfem/mumps/lib/libzmumps.a
> >>> > U blacs_gridinit_
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U Cblacs_gridinit
> >>> > U blacs_gridinit_
> >>> > U blacs_gridinit_
> >>> > U blacs_gridinit_
> >>> > U blacs_gridinit_
> >>> > U blacs_gridinit_
> >>> > U blacs_gridinit_
> >>> > U blacs_gridinit_
> >>> > U blacs_gridinit_
> >>> > symbol exists in
> >>> > library /home/bettella/trilfem/scalapack/libscalapack.a
> >>> >
> >>> >
> >>> > everything else is basically copies of these in other places (which
> >>> > I'm aware of)
> >>> > I think the U means undefined, is this the problem?
> >>> >
> >>> >
> >>> > On Wed, Jun 18, 2008 at 4:33 PM, Richard George <
address@hidden>
> >>> > wrote:
> >>> > Hi Daniele,
> >>> >
> >>> > here's a few things you could try?
> >>> >
> >>> >
> >>> >
> >>> > 1. where is the file libblacs.a on your machine?
> >>> >
> >>> > 2. when you type ./configure ..........
> >>> >
> >>> > do you know that each ${VARIABLE} is set correctly?
> >>> > eg. does ./configure know which directories you mean by
> >>> >
> >>> > ${GETFEMDIR} ${TRILINOSDIR} ${BLACSDIR} ${MUMPSDIR}
> >>> >
> >>> > does
> >>> >
> >>> > echo ${GETFEMDIR}
> >>> > echo ${TRILINOSDIR}
> >>> > echo ${BLACSDIR}
> >>> > echo ${MUMPSDIR}
> >>> >
> >>> > produce the expected results?
> >>> >
> >>> > if not, perhaps you need to type
> >>> >
> >>> > export GETFEMDIR="/...your path to getfem"
> >>> > export BLACSDIR="/....your path to blacs"
> >>> > ....
> >>> >
> >>> > or manually replace the ${BLACSDIR} with the correct path in
> >>> > the
> >>> > configure command arguments before running ./configure?
> >>> >
> >>> > 3. It sounds like the linker is not finding the routine
> >>> > 'blacs_gridinit_'
> >>> >
> >>> > you can use the command
> >>> >
> >>> > nm -s libname.a
> >>> >
> >>> > to list the symbols in the library "libname.a"
> >>> >
> >>> > and grep to filter the output for the specific one you want,
> >>> > eg.
> >>> > copy and paste this into a bash shell, to search your home
> >>> > directory for
> >>> > any library .a file containing the routine blacs_gridinit
> >>> > ----
> >>> >
> >>> > SEARCH_PATH=/home/bettella
> >>> > SYMBOL_NAME=blacs_gridinit
> >>> >
> >>> > IFS=$'\n'
> >>> >
> >>> > for f in $(find $SEARCH_PATH -type f | grep \\.a$); \
> >>> > do nm -s $f 2>&1 | grep -i $SYMBOL_NAME; \
> >>> > if [ "$?" -eq "0" ]; \
> >>> > then echo symbol exists in library $f; \
> >>> > fi; done
> >>> >
> >>> >
> >>> > -----
> >>> > or, to search installed libraries on the system,
> >>> > -----
> >>> >
> >>> > SEARCH_PATH=/usr/lib
> >>> > SYMBOL_NAME=blacs_gridinit
> >>> >
> >>> > IFS=$'\n'
> >>> >
> >>> > for f in $(find $SEARCH_PATH -type f | grep \\.a$); \
> >>> > do nm -s $f 2>&1 | grep -i $SYMBOL_NAME; \
> >>> > if [ "$?" -eq "0" ]; \
> >>> > then echo symbol exists in library $f; \
> >>> > fi; done
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Wed, 2008-06-18 at 12:55 +0200, Daniele Bettella wrote:
> >>> > > I'm trying to understand how things work...
> >>> > > it would look as if mumps was built without linking to
> >>> > scalapack and
> >>> > > blacs, am I wrong?
> >>> > > the proper libraries were included in mumps makefile (and
> >>> > mumps tests
> >>> > > work properly), but in the building process of libdmumps.a I
> >>> > can't see
> >>> > > them used anywhere, although it surely uses them when
> >>> > building the
> >>> > > tests (and that's why they work); so going back to getfem I
> >>> > should be
> >>> > > able to make check flawlessly by linking the same libraries
> >>> > as those
> >>> > > used for mumps tests (plus those needed by getfem itself)...
> >>> > so why
> >>> > > isn't it working?
> >>> > >
> >>> > > On Tue, Jun 17, 2008 at 10:33 AM, Daniele Bettella
> >>> > <
address@hidden>
> >>> > > wrote:
> >>> > > Hello and thanks for your answers, I added scalapack
> >>> > to the
> >>> > > list of linked libs on getfem, but it solves
> >>> > nothing;
> >>> > > regarding pblas I can't seem to find it, it should
> >>> > be part of
> >>> > > scalapack or something like that, but a libpblas
> >>> > wasn't
> >>> > > created. (btw, I'm compiling everything from
> >>> > source).
> >>> > > I should add the among the undef reference there's
> >>> > something
> >>> > > specifically about blacs (which is already linked in
> >>> > getfem
> >>> > > configure):
> >>> > >
> >>> >
> >>>
> /home/bettella/trilfem/mumps/lib/libdmumps.a(dmumps_part6.o)(.text+0x158fe):
> >>> In function `dmumps_164_':
> >>> > > : undefined reference to `blacs_gridexit_'
> >>> > >
> >>> >
> >>>
> /home/bettella/trilfem/mumps/lib/libdmumps.a(dmumps_part6.o)(.text+0x15941):
> >>> In function `dmumps_164_':
> >>> > > : undefined reference to `blacs_gridinit_'
> >>> > >
> >>> >
> >>>
> /home/bettella/trilfem/mumps/lib/libdmumps.a(dmumps_part6.o)(.text+0x15977):
> >>> In function `dmumps_164_':
> >>> > > : undefined reference to `blacs_gridinfo_'
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Mon, Jun 16, 2008 at 7:51 PM, Richard George
> >>> > > <
address@hidden> wrote:
> >>> > > Hi there,
> >>> > >
> >>> > > possibly you need to link against pblas
> >>> > instead of
> >>> > > blas, eg.
> >>> > >
> >>> > > BLAS_LIBS=-lpblas
> >>> > >
> >>> > > + did you compile everything locally, or did
> >>> > you
> >>> > > install some binary
> >>> > > packages?
> >>> > >
> >>> > > I ask because the make file tests how the
> >>> > fortran
> >>> > > compiler mangles the
> >>> > > names of the routines it generates, eg, the
> >>> > routine
> >>> > > "numroc" in the
> >>> > > source appears as a function "numroc_" in
> >>> > the object
> >>> > > code,
> >>> > >
> >>> > > but it might have been called "_numroc" or
> >>> > > "__numroc" (etc) depending on
> >>> > > which brand of fortran compiler you are
> >>> > using. The
> >>> > > makefile compiles a
> >>> > > short fortran routine and inspects how the
> >>> > output is
> >>> > > named, assuming the
> >>> > > make file is calling the same brand of
> >>> > fortran
> >>> > > compiler as was used to
> >>> > > compile the libraries.
> >>> > >
> >>> > > If it's all compiled locally that's unlikely
> >>> > to be an
> >>> > > issue.
> >>> > >
> >>> > > best of luck
> >>> > >
> >>> > > Richard
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Sun, 2008-06-15 at 23:07 +0200, Daniele
> >>> > Bettella
> >>> > > wrote:
> >>> > > > No one?
> >>> > > >
> >>> > > > On Wed, Jun 11, 2008 at 11:53 AM, Daniele
> >>> > Bettella
> >>> > > <
address@hidden>
> >>> > > > wrote:
> >>> > > > Hi, I'm trying to compile getfem
> >>> > with
> >>> > > parallel support, I'm
> >>> > > > using this configure script
> >>> > > >
> >>> > > > ./configure --prefix=${GETFEMDIR}
> >>> > > --enable-shared
> >>> > > > --enable-python
> >>> > --with-pic
> >>> > > > BLAS_LIBS=-lblas
> >>> > > > CXXFLAGS="-I
> >>> > > ${TRILINOSDIR}/include -D
> >>> > > > GETFEM_PARA_LEVEL=2 -I
> >>> > ${MUMPSDIR}/include"
> >>> > > > MUMPS_CFLAGS="-I
> >>> > > ${MUMPSDIR}/include"
> >>> > > > MUMPS_LIBS="-L
> >>> > ${MUMPSDIR}/lib
> >>> > > -lcmumps -ldmumps
> >>> > > > -lsmumps -lzmumps -lpord"
> >>> > > > LDFLAGS="-L
> >>> > ${TRILINOSDIR}/lib
> >>> > > -lepetra -ltriutils
> >>> > > > -laztecoo -lteuchos
> >>> > > > -L
> >>> > ${METISDIR}
> >>> > > -lmetis -lparmetis
> >>> > > > -L${MUMPSDIR}/lib -ldmumps
> >>> > > >
> >>> > -lcmumps
> >>> > > -ldmumps -lsmumps
> >>> > > > -lzmumps -lpord -llapack
> >>> > > > -L
> >>> > ${BLACSDIR}
> >>> > > -lblacsF77 -lblacs
> >>> > > > -lblacsC"
> >>> > > >
> >>> > CC=mpicc
> >>> > > CXX=mpicxx F77=mpif77
> >>> > > >
> >>> > > >
> >>> > > > Getfem compilation works fine, but
> >>> > on make
> >>> > > check I have the
> >>> > > > following error message when
> >>> > compiling
> >>> > > elastostatic:
> >>> > > >
> >>> > >
> >>> >
> >>>
> /home/bettella/trilfem/mumps/lib/libdmumps.a(dmumps_part3.o)(.text+0xbd54):
> >>> In function `dmumps_270_':
> >>> > > > : undefined reference to `numroc_'
> >>> > > >
> >>> > > >
> >>> > > > many other undef reference follow,
> >>> > they all
> >>> > > seem to be
> >>> > > > reffered to blacs routines, mumps
> >>> > was
> >>> > > installed with the
> >>> > > > following makefile.inc (for what
> >>> > regards
> >>> > > blacs)
> >>> > > > BLACSFINIT
> >>> > > = /home/bettella/trilfem/blacs/blacsF77.a
> >>> > > > BLACSCINIT
> >>> > > = /home/bettella/trilfem/blacs/blacsC.a
> >>> > > > BLACSLIB
> >>> > > = /home/bettella/trilfem/blacs/blacs.a
> >>> > > > SCALAP = -lscalapack $(BLACSLIB)
> >>> > > $(BLACSCINIT) $(BLACSFINIT)
> >>> > > > $(BLACSLIB)
> >>> > > >
> >>> > > > mumps compiles fine and the tests
> >>> > run ok
> >>> > > >
> >>> > > > I know my configure script for
> >>> > getfem is a
> >>> > > little messy, but
> >>> > > > I'm struggling to find a solution
> >>> > fort this
> >>> > > problem...
> >>> > > > any help would be very
> >>> > appreciated.
> >>> > > >
> >>> > > > Daniele
> >>> > > >
> >>> > > >
> >>> > >
> >>> > > >
> >>> > _______________________________________________
> >>> > > > Getfem-users mailing list
> >>> > > >
address@hidden
> >>> > > >
https://mail.gna.org/listinfo/getfem-users
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>> >
> >>>
> >>>
> >>
> >
>