[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Getfem-users] problem on make check
|
From: |
Julien Pommier |
|
Subject: |
Re: [Getfem-users] problem on make check |
|
Date: |
Wed, 02 Jul 2008 14:14:55 +0200 |
|
User-agent: |
Internet Messaging Program (IMP) 3.2.6 |
Hi Daniele,
You're missing the evilness of libtool which is as usual trying to be smart, and
fails ! My suggestion is to bypass it and just try to run the huge link command
"mpicxx -I/home/bettella/trilfem/trilinos/include -D(...etc)" by hand , just
write it in a small shell script and do you permutations attempts from there
instead of running the whole "./configure && make" artillery each time.
(I hate libtool)
--
Julien
Quoting Daniele Bettella <address@hidden>:
> Thanks for your answer; I tried several permutations of the libraries, but
> it looks nothing helps... the thing I can't understand is that wathever I
> write in the configure script (wrt the permutations of libraries) the last
> command make check runs before the error is this:
>
> 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/scalapack
> -L/home/bettella/trilfem/blacs -L/home/bettella/trilfem/trilinos/lib
> -L/home/bettella/trilfem/metis -L/home/bettella/trilfem/mumps/lib
> ../src/.libs/libgetfem -lblacsF77 -lblacsC -lepetra -ltriutils -laztecoo
> -lteuchos -lmetis -lparmetis -lscalapack -llapack -lblacs
> /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
>
> although before I have this:
>
> /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/scalapack -lscalapack
> -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 -lblacs -o elastostatic elastostatic.o ../src/
> libgetfem.la -lm -L/home/bettella/trilfem/mumps/lib -lcmumps -ldmumps
> -lsmumps -lzmumps -lpord -lblas
>
> which lists the exact order in which I wrote the libraries in the configure
> script...
>
> am I missing something?
>
>
> On Wed, Jul 2, 2008 at 12:39 AM, Julien Pommier <
> address@hidden> wrote:
>
> > Quoting Daniele Bettella <address@hidden>:
> >
> > > 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 <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
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> >
> >
> >
> >
>