dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday June 1 2010 10:32:43 kent-and@xxxxxxxxx wrote:
> > 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.

Ok. I think this gets too complicated to fix at the module signature level. 

I would suggest you to use different INSTANT_CACHE_DIR variables for the 
different DOLFIN builds.

Johan