dolfin team mailing list archive

[kent-and@xxxxxxxxx]

> On Saturday May 29 2010 03:05:42 kent-and@xxxxxxxxx wrote:
>> > On Fri, May 28, 2010 at 09:01:22AM -0700, Johan Hake wrote:
>> >> On Thursday May 27 2010 23:28:19 Kent Andre wrote:
>> >> > On Thu, 2010-05-27 at 18:52 -0700, Johan Hake wrote:
>> >> > > You can controll this by setting the environment variable:
>> >> > >   INSTANT_CACHE_DIR
>> >> > >
>> >> > > to different directories for the different DOLFIN builds.
>> >> > >
>> >> > > If you use different conf files for the different DOLFIN builds
>> you
>> >>
>> >> can
>> >>
>> >> > > easily controll the instant cache dir from within these.
>> >> > >
>> >> > > We once included the dolfin version in the cache id, but it was
>> >>
>> >> removed
>> >>
>> >> > > as it the ufc python module is not dependent on anything in
>> dolfin.
>> >>
>> >> Not
>> >>
>> >> > > sure how true this is in reality though.
>> >> > >
>> >> > > What kind of troubles have you encountered?
>> >> > >
>> >> > > Johan
>> >> >
>> >> > The shared library in the cache is linked against another Dolfin
>> and
>> >> > therefore it wouldn't load.
>> >>
>> >> Ok I see. We are including the __version__ in the signature of the
>> >> instant
>> >> module, but if you are using the latest stable version together with
>> a
>> >> development version, you get the same version number, which wont
>> trigger
>> >> a new
>> >> module.
>> >>
>> >> One way to fix this is to increase the version on all development
>> >> versions.
>> >> This would make sense as we are no longer developing the 0.9.7, which
>> is
>> >> released. We are developing 0.9.8, which is then reflected by the
>> >> __version__
>> >> string. Other softwares use this convention too.
>> >>
>> >> If we want to be water proof we could look up libdolfin.so and take a
>> >> md5 sum
>> >> of the file and use that in the signature. We then need to use
>> different
>> >> suffixes and prefixes for the different platforms.
>> >
>> > We should set the number to "x.y.z+" right after the release.
>> >
>> > This is done in FFC (as part of the post-release hook) and it needs to
>> > be done also in DOLFIN. I'll add this to the DOLFIN post-release hook.
>> >
>> > --
>> > Anders
>>
>> I think we should go for the water proof solution and use info either
>> from
>> the library or compiler options + version numbers. The compiler options
>> solution might be the simplest portable solution (?).
>> It should be simple enough to do.
>
> What exactly was the problem? Was it binary incompatability of two
> different
> libdolfin from the development build? We have not exposed the
> compilerflags to
> dolfin extension modules. By default they are compiled using -O2. Or was
> it
> the compilerflags for libdolfin that caused the problem, and if so, how
> could
> that be?
>
> Johan
>

The shared library from the cache would not load. This shared library was
linked
against another dolfin of the same version, but compiled/linked in another
way. I
don't think it had to do with the -O2 or similar options, but rather that
it was
linked against another set of libraries (Trilinos, PETSc, etc.). Some of
these are e.g. not in LD_LIBRARY_PATH for the dolfin in use.

Kent