dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Tuesday 02 June 2009 14:56:45 Martin Sandve Alnæs wrote:
> On Tue, Jun 2, 2009 at 1:43 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> > 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.
>
> That is not at all an acceptable solution, it requires that I modify
> other parts of the system, parts that I may not even have access too.
>
> > 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?
>
> Not sure about FOO_DIR, but withFOODir is a direct command
> to the build system that should not be replaced by the default
> system-wide option.
>
> > 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.
>
> This has nothing to do with cache (conceptually, don't know about
> the implementation), this was the _first_ installation using dorsal.

If you have a pkg-config file installed, scons has no way of knowing that it 
should not use that. If it is an erronious system wide file you cannot 
delete, we have a problem.

> Anyway, the cache system would still be broken if it ignored
> my explicit "withPetscDir" argument. I ask for a specific version,
> and scons gives me an arbitrary version it found on the system.
> That's not a feature...

Well, the withPetscDir option will be cached, and the second time you issues 
the command you write just scons. Is this an explicit argument then? 

Would it be possible to handle the withFOODir options differently if they are 
called explicitly and not from cache? Maybe by setting some sort of flag to 
the internal option handling in dolfin scons? If it was set explicitly we 
regenerate the pkg-config file?

> > 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.
>
> Again, this isn't (only) about cache.

I think it is, but we need to find solutions for the corner cases and you have 
obviously come a cross one.

Johan

> Martin