dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Tuesday 02 June 2009 12:37:51 Martin Sandve Alnæs wrote:
> On Tue, Jun 2, 2009 at 12:34 PM, Johannes Ring <johannr@xxxxxxxxx> wrote:
> > On Tue, June 2, 2009 12:24, Martin Sandve Alnæs wrote:
> >> On Tue, Jun 2, 2009 at 10:47 AM, Johan Hake <hake@xxxxxxxxx> wrote:
> >>> On Tuesday 02 June 2009 10:28:11 Martin Sandve Alnæs wrote:
> >>>> I've tried to use dorsal on my home laptop which I just upgraded to
> >>>> Jaunty.
> >>>> I got some problems with trilinos (Harish: same as on my work laptop),
> >>>> and will recompile now after removing all trilinos.pc files around the
> >>>> system.
> >>>>
> >>>> I see from scons --help in dolfin that the path has been set correctly
> >>>> there:
> >>>>
> >>>> withTrilinosDir: Specify path to Trilinos ( /path/to/withTrilinosDir )
> >>>>     default: None
> >>>>     actual: /opt/fenics904
> >>>>
> >>>> I've found two issues I will call bugs:
> >>>>
> >>>> 1) dolfin scons didn't copy the trilinos.pc it generated to the
> >>>> installation directory. Should be an easy fix in dolfin scons.
> >>>
> >>> This sounds strange. This line in the SConstruct file should do that:
> >>>
> >>>  # We also like to install all generated pkg-config files.
> >>>  buildDataHash["pkgconfig"] +=
> >>>    scons.globFiles(Dir("#/scons/pkgconfig/").srcnode().abspath, "*.pc")
> >>
> >> I can find no such line:
> >>
> >> martinal@martinal-znote:~/dev/fenics904/dolfin-0.9.2$ find -name
> >> SConscript
> >> ./data/SConscript
> >> ./doc/SConscript
> >> ./dolfin/SConscript
> >> ./demo/SConscript
> >> ./test/SConscript
> >> ./sandbox/ilmarw/assembler_bench/Stokes_2D_TH/SConscript
> >> ./sandbox/ilmarw/assembler_bench/Laplace_2D/SConscript
> >> ./sandbox/ilmarw/assembler_bench/ICNS_3D_Momentum/SConscript
> >> ./sandbox/ilmarw/assembler_bench/Elasticity_3D/SConscript
> >> ./sandbox/ilmarw/assembler_bench/Stokes_2D_Stab/SConscript
> >> martinal@martinal-znote:~/dev/fenics904/dolfin-0.9.2$ find -name
> >> SConscript | xargs egrep buildData
> >
> > In DOLFIN 0.9.2 buildDataHash is called ret and the line you are looking
> > for is 381 in dolfin/SConscript.
> >
> >>> Where is your trilinos.pc situated?
> >>
> >> Which one? I had several before, one in the path.
> >> scons made a new one placed in the repository,
> >> now I've copied that manually to the installation directory.
> >> The libgaleri problem is now gone after the rebuild.
> >>
> >>
> >> Compiling C++ demos works fine now, but "import dolfin" gives:
> >>
> >> ImportError: /opt/fenics904/lib/libdolfin.so.0: undefined symbol:
> >> _Z26KSPMonitorTrueResidualNormP6_p_KSPidPv
> >>
> >> In [2]:
> >> Do you really want to exit ([y]/n)?
> >> martinal@martinal-znote:~$ c++filt
> >> _Z26KSPMonitorTrueResidualNormP6_p_KSPidPv
> >> KSPMonitorTrueResidualNorm(_p_KSP*, int, double, void*)
> >>
> >>
> >>
> >> Turns out that petsc isn't handled correctly either. It's built and
> >> installed by dorsal,
> >> and dolfin scons gets the right directory for it,
> >>
> >> withPetscDir: Specify path to PETSc ( /path/to/withPetscDir )
> >>     default: None
> >>     actual: /opt/fenics904
> >>
> >> But no pkg-config file has even been generated in this case:
> >> martinal@martinal-znote:~/dev/fenics904/dolfin-0.9.2$ ls
> >> scons/pkgconfig/ boost.pc  gmp.pc  mtl4.pc  parmetis.pc  scotch.pc
> >>  trilinos.pc
> >
> > No, because you already have one that is found in $PKG_CONFIG_PATH.
>
> I consider this behaviour a significant bug. A new one should be generated
> if the $PKG_CONFIG_PATH version doesn't match the manually specified
> version.

This issue is returning, again and again. An old installed pkg-config file 
screws the construction and installation of new ones. Been there me too...

The present "solution" has been to either manually delete it or run 

  scons install -c

The later does only remove any pkg-config files in the install path and might 
miss out on others.

So you suggest that we should check for the version of any installed 
pkg-config files and compare that to any manually specified libraries, let it 
be using FOO_DIR or withFOODir? 

This is probably a not so intrusive check, however we should remember that 
caching is a feature. If we add too many checks the whole point of having 
cached pkg-config files goes away.

To make a version check consistant we should probably add checks not only for 
PETSc but for all other external dependencies too. Complicating the build 
when everything is fine.

Are there any other way of doing this? Can we add an un-cachable option for 
running all pkg-config tests again? This would produce new pkg-config files, 
which would be installed when scons install is issued.

Johan

> Martin