dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Sep 21, 2009 at 06:49:56PM +0100, Garth N. Wells wrote:
>
>
> Andre Massing wrote:
> > Hi,
> >
> > Johan Hake wrote:
> >> On Sunday 20 September 2009 13:24:13 Andre Massing wrote:
> >>> Hi,
> >>>
> >>> I just reinstalled all fenics and related packages for testing/benchmark
> >>> purposes via dorsal (except dolfin itself) and configure, compiled and
> >>> install dolphin via scons.local. And just to be sure, I deleted every
> >>> pkgconfig file I came across :) Unfortunately if I try to run the
> >>> SConstruct file in the demo/function/eval/cpp directory I get the
> >>> following linking error (I sourced dolfin.conf in beforehand...)
> >>>
> >>> scons: Reading SConscript files ...
> >>> scons: done reading SConscript files.
> >>> scons: Building targets ...
> >>> mpic++ -o demo -Wl,-rpath,/home/andre/local/lib -pthread
> >>> -Wl,--export-dynamic main.o
> >>> -L/home/andre/homebase/software/packages/src/fenics-unstable/dolfin/local/l
> >>> ib -L/home/andre/local/lib -L/usr/lib/atlas -lCGAL -lCGAL_Core -ldolfin
> >>>  -lboost_filesystem-mt -lz -lslepc -lml -lifpack -lamesos -laztecoo
> >>>  -lteuchos -lepetra -lepetraext -lumfpack -lboost_program_options-mt -lgts
> >>>  -lm -llapack -lblas -lcholmod -lamd -lcolamd -lparmetis -lmetis -lgmp
> >>>  -lgmpxx -lscotch -lscotcherr -lxml2 -lpetscts -lpetscsnes
> >>> -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -lgthread-2.0 -lrt
> >>> -lgmodule-2.0 -lglib-2.0
> >>> /home/andre/homebase/software/packages/src/fenics-unstable/dolfin/local/lib
> >>> /libdolfin.so: undefined reference to `mtl::vector::dense_vector<double,
> >>> mtl::vector::parameters<mtl::tag::col_major,
> >>> mtl::vector::non_fixed::dimension, false, false> >::size_type
> >>> mtl::vector::num_rows<double,
> >>> mtl::vector::parameters<mtl::tag::col_major,
> >>> mtl::vector::non_fixed::dimension, false, false>
> >>>
> >>>  >(mtl::vector::dense_vector<double,
> >>>
> >>> mtl::vector::parameters<mtl::tag::col_major,
> >>> mtl::vector::non_fixed::dimension, false, false> > const&)'
> >>> collect2: ld returned 1 exit status
> >>> scons: *** [demo] Error 1
> >>>
> >>> Since mtl4 is so heavily template based I would expect some -I option to
> >>> include right mtl paths, but I am just blindly guessing...
> >>> Maybe any ideas what went wrong?
> >> What version of mtl4 do you have. I have 6821 and it works fine.
> >
> > I use 6848 (today's version as dorsal does a svn update within an
> > existing mtl4 directory)
> >
> >> You are showing the output from the linking stage and this should be fine
> >> without any references to any mtl4 path, as mtl4 is (as far as I know) a pure
> >> header library.
> >
> > Oh yepp right, accidentally looked and copied the messages from the
> > second run...
> >
> > Just investigated the problem and there were a changes in the mtl4
> > trunk, updating to your revision actually resolved the problem (note to
> > me: should have done this first :))
> > A svn diff of the revisions showed that basically the implementation of
> > the function num_rows and num_cols were changed.
> >
> > Oh man, installation of bleeding edge software makes always fun and gets
> > you never bored :)
> >
>
> I've been running into a few problems with MTL4 lately. The developers
> do not test MTL4 with the '-Wall' flag, which means that they don't pick
> up issues which give us problems. Is it an idea to remove the MTL4
> backend? We can add it back later if it becomes more stable. Opinions?

Depends on whether someone wants to keep tracking MTL4 and at least
occasionally make sure it works. You've been doing a good job so far,
but if you want to drop it and no one else wants to pick it up, I
don't mind dropping it.

--
Anders

Attachment: signature.asc
Description: Digital signature