Quoting Daniele Bettella <[EMAIL PROTECTED]>: > Is anybody able to help? Even sending a configure script that do work (for > you) with mumps and getfem_para_level=2 would be nice... >
Have you tried some permutations of the various libraries ? If numroc is part of blacs, I would try to append it one more time at the end of the command line -- Julien > On Mon, Jun 23, 2008 at 9:00 AM, Daniele Bettella <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > >>> > 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 > >>> > <[EMAIL PROTECTED]> > >>> > > 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 > >>> > > <[EMAIL PROTECTED]> 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 > >>> > > <[EMAIL PROTECTED]> > >>> > > > 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 > >>> > > > [email protected] > >>> > > > https://mail.gna.org/listinfo/getfem-users > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> > > >>> > >>> > >> > > > _______________________________________________ Getfem-users mailing list [email protected] https://mail.gna.org/listinfo/getfem-users
