On Tuesday June 1 2010 10:32:43 [email protected] wrote: > > On Saturday May 29 2010 03:05:42 [email protected] 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
