> 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. Kent _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
