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...

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

Reply via email to