dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Tuesday June 1 2010 13:39:47 Kent Andre wrote:
> On Tue, 2010-06-01 at 10:59 -0700, Johan Hake wrote:
> > 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
> 
> I can use the INSTANT_CACHE_DIR variable, sure :)
> 
> But, it should not be to hard to do. In instant it is easy to
> add compiler/linker options to the signature. One option is
> use both the .i file and the setup file to generate the checksum.
> 
> Similar can be done in dolfin. Or to speed up the process, a
> dolfin library specific signature could be generated during
> compilation.

I agree that this is possible, and I agree that it would be nice! 

The _only_ thing we need is to find the library binary which we link to during 
JIT compiling and add a hash sum of that file to the signature. 

If you have a fool proof, portable and short way of finding the binary, please 
feel free to share it!

Johan



> This would probably get rid of some of the 'instant-clean's that
> mysteriously remove troubles.
> 
> Kent