dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On Tue, Jun 2, 2009 at 3:17 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> 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.

Yes it has, I specify which directory it should use on the command line.
The information is there, but the scons system _choose_ to not use it.

One very common reason for having to specify your own library
directories is when compiling in a multiuser environment.
For example at our cluster, I can't control what's installed or not globally.
Any other multiuser environments is likely to have the same 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?

Since arguments are cached, the behaviour should be equivalent to
specifying them directly. I don't know how scons works, and I don't
really care how that's implemented. Caching is an optimization,
and shouldn't change expected behaviour.


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

I leave that to scons people. Just keep in mind that
a "cache system" that changes the behaviour is either:
A) NOT a cache system
B) Broken


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

I would hardly call this a corner case. It seems to me this is
the cause of build problems for a _lot_ of people all the time.

Martin