On 1 Aug 2014, at 19:54, Mikael Mortensen <[email protected]> wrote:
> Thank you both for the tips. I’ll look into it some more. BTW, do you create > your own modules for all dependencies Garth? The module system is used on our > cluster, but I have never tried to create modules of my own. > I haven’t done it, but have seen colleagues do it for FEniCS (on workstations and on clusters). It’s easy. Dorsal should create module files. Garth > Best regards > > Mikael > > On 01 Aug 2014, at 18:20, Garth N. Wells <[email protected]> wrote: > >> Use the 'module' system to support multiple installations on a cluster. >> >> Garth >> >> On Fri, 1 Aug, 2014 at 3:36 PM, Jan Blechta <[email protected]> >> wrote: >>> On Fri, 1 Aug 2014 16:16:38 +0200 >>> Mikael Mortensen <[email protected]> wrote: >>>> Hi, >>>> I'm trying to install master version of fenics on top of a stable >>>> version installed by Johannes on the Abel cluster. Johannes has more >>>> or less everything, including dolfin, installed under >>>> /usit/abel/u1/johannr/nobackup/src/hashstack/default/, which is on my >>>> path. The stable version here works just fine. I now want to use all >>>> the dependencies here and build a master version, so I'm using dorsal >>>> with unstable for fiat/ffc/ufl/instant, and install in my own folder. >>>> I then clone dolfin in a different directory and run cmake.local. It >>>> stops at MultiMeshAssembler.cpp because for some reason it picks up >>>> ufc.h from the stable and not the unstable branch, even though the >>>> unstable is sourced last. From my .bashrc: >>>> source /usit/abel/u1/johannr/fenics-1.4.0-gcc.conf # stable >>>> everything >>>> source /usit/abel/u1/mikaem/Fenics/fenics-1.4/share/fenics/fenics.conf >>>> # unstable fiat/ffc/ufl/instant/ufc.h >>>> With some hacking of paths I am able to fix MultiMeshAssembler and >>>> everything compiles just fine. However, the python version still does >>>> not work and I find that it is because the module-libraries are >>>> picking up the stable dolfin version. Here is ldd of >>>> dolfin/cpp/_common.so: >>>> [mikaem@login-0-0 ~]$ ldd >>>> /usit/abel/u1/mikaem/Fenics/dolfin/local.master/lib/python2.7/site-packages/dolfin/cpp/_common.so >>>> linux-vdso.so.1 => (0x00007fff7816d000) >>>> libdolfin.so.1.4 => >>>> /usit/abel/u1/johannr/nobackup/src/hashstack/default/lib/libdolfin.so.1.4 >>>> (0x00007fb14c5ee000) >>>> libpython2.7.so.1.0 => >>>> /usit/abel/u1/johannr/nobackup/src/hashstack/default/lib/libpython2.7.so.1.0 >>>> (0x00007fb14c1e7000) >>>> ... >>>> Evidently _common.so has picked up the stable libdolfin.so.1.4. Any >>>> hints at how this can be fixed? An alternative I don't like is to >>>> give up Johannes' dependencies all together and install everything >>>> for myself. >>> You should not use Johannes' fenics.conf, it probably sets >>> LD_LIBRARY_PATH. Linker can't distinguish between stable and unstable as >>> they have same name libdolfin.so.1.4. Rather you should tell to DOLFIN's >>> CMake about all the dependencies which you want to use from Johannes. >>> Or maybe try a little bit messy solution, keep the build you have and >>> then get rid of Johannes' LD_LIBRARY_PATH in your own fenics.conf a >>> check what linker says. >>> Generally, it will be everytime tricky. You should convince Johannes to >>> install dependencies you need separately from stable FEniCS. (You could >>> simulate this with symlinks.) >>> Jan >>>> Thanks for any help. >>>> Best regards >>>> Mikael >>> _______________________________________________ >>> fenics-support mailing list >>> [email protected] >>> http://fenicsproject.org/mailman/listinfo/fenics-support >> > _______________________________________________ fenics-support mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics-support
