dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Mar 13, 2008 at 12:24:31PM +0100, johannr@xxxxxxxxx wrote:
> On Thu, Mar 13, 2008 Anders Logg wrote:
> > On Wed, Mar 12, 2008 at 08:48:52PM +0100, Åsmund Ødegård wrote:
> >> On Wed, Mar 12, 2008 at 8:35 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> >> >
> >> > On Wed, Mar 12, 2008 at 08:29:39PM +0100, Johan Hake wrote:
> >> >  > On Wednesday 12 March 2008 18:56:08 Anders Logg wrote:
> >> >  > > On Wed, Mar 12, 2008 at 11:48:19AM +0100, Johan Hake wrote:
> >> >  > > > On Tuesday 11 March 2008 17:47:09 Matthew Knepley wrote:
> >> >  > > > > On Tue, Mar 11, 2008 at 11:40 AM, Anders Logg
> >> <logg@xxxxxxxxx> wrote:
> >> >  > > > > > Compiling and running C++ applications against DOLFIN now
> >> works fine
> >> >  > > > > >
> >> >  > > > > >  for me, but it breaks in Python:
> >> >  > > > > >  >>> from dolfin import *
> >> >  > > > > >
> >> >  > > > > >  Traceback (most recent call last):
> >> >  > > > > >   File "<stdin>", line 1, in <module>
> >> >  > > > > >   File
> >> >  > > > > >   "/home/logg/local/lib/python2.5/site-packages/dolfin/__init__.py",
> >> >  > > > > >   line 4, in <module>
> >> >  > > > > >     from assemble import *
> >> >  > > > > >   File
> >> >  > > > > >   "/home/logg/local/lib/python2.5/site-packages/dolfin/assemble.py",
> >> >  > > > > >   line 17, in <module>
> >> >  > > > > >     from dolfin import *
> >> >  > > > > >   File
> >> >  > > > > >   "/home/logg/local/lib/python2.5/site-packages/dolfin/dolfin.py",
> >> >  > > > > >   line 7, in <module>
> >> >  > > > > >     import _dolfin
> >> >  > > > > >  ImportError: libpetscsnes.so: cannot open shared object
> >> file: No
> >> >  > > > > > such file or directory
> >> >  > > > > >
> >> >  > > > > >  # pkg-config --libs dolfin
> >> >  > > > > >  -Wl,-rpath,/usr/local/lib/petsc/lib/linux-gnu-cxx-debug
> >> -pthread
> >> >  > > > > >  -Wl,--export-dynamic -L/home/logg/local/lib
> >> -L/usr/lib/atlas
> >> >  > > > > >  -L/usr/local/lib/petsc/lib/linux-gnu-cxx-debug -ldolfin
> >> -lblas
> >> >  > > > > >  -llapack -lumfpack -lamd -lpetscsnes -lpetscmat -lpetscvec
> >> -lpetscts
> >> >  > > > > >  -lpetsc -lpetscdm -lpetscksp -lgts -lxml2 -lgthread-2.0
> >> -lrt
> >> >  > > > > >  -lgmodule-2.0 -ldl -lglib-2.0
> >> >  > > > > >
> >> >  > > > > >  Any ideas?
> >> >  > > > > >
> >> >  > > > > >  I guess the path to PETSc libraries was built into
> >> libdolfin.so in
> >> >  > > > > >  some way before, but not anymore?
> >> >  > > > >
> >> >  > > > > Either you put -Wl,-rpath options in along with the -L
> >> options, or
> >> >  > > > > you do some incantation with ldconfig (not my preferred
> >> option).
> >> >  > > >
> >> >  > > > This is possible whith scons, but Åsmund actively descided to
> >> not use it
> >> >  > > > for simula-scons. He has experienced some problems with darwin.
> >> Maybe
> >> >  > > > Åsmund can elaborate?
> >> >  > > >
> >> >  > > > Johan
> >> >  > >
> >> >  > > But how does it help to put in the -Wl,-rpath options to
> >> pkg-config
> >> >  > > --libs when importing the DOLFIN Python module into Python? As
> >> far as
> >> >  > > I know, Python does not call pkg-config, or should these options
> >> be
> >> >  > > present when compiling the SWIG-generated wrapper?
> >> >  >
> >> >  > I understand the -Wl,-rpath options as "hardcoding" the path to
> >> external
> >> >  > shared library at compile/linking time, so you do not have to
> >> provide it
> >> >  > during runtime with e.g. the LD_LIBRARY_PATH. As far as I know the
> >> old dolfin
> >> >  > build system included this information when the wrapper code was
> >> generated.
> >> >  >
> >> >  > It wont help putting this path into the pkg-config file as any such
> >> >  > information will be ignored when parsed by simula-scons, and wont
> >> be used.
> >> >  > Åsmund can probably elaborate on the why's here.
> >> >  >
> >> >  > > Does PyDOLFIN work for anyone else with the new build system?
> >> >  >
> >> >  > Here it works fine. I have compiled with petsc, and I have its path
> >> in the
> >> >  > LD_LIBRARY_PATH.
> >> >
> >> >  It works for me also if I add the location of PETSc to my
> >> LD_LIBRARY_PATH.
> >> >  Is this how it's supposed to work?
> >> >
> >> >  It seems strange that you both need to set a PETSC_DIR and then also
> >> >  have PETSC_DIR/lib/$arch/ in the LD_LIBRARY_PATH.
> >> >
> >> >  Either there's a PETSC_DIR *or* PETSc is installed somewhere (in
> >> which
> >> >  case it needs to be in a standard place like /usr/lib or in the
> >> >  LD_LIBRARY_PATH)?
> >>
> >> That's obvious, isn't it? Either you have to link statically, in that
> >> case PETSC_DIR could be used during compile. Or you link dynamically,
> >> and the linker have to know where to look during run. Either by using
> >> LD_LIBRARY_PATH or ldconfig.
> >
> > Yes! I agree, but it seems that this is not the case.
> >
> > My PETSc installation is in some location only known by
> > PETSC_DIR. This means I must set PETSC_DIR when building DOLFIN.
> >
> > I then expect to be able to build applications against the compiled
> > DOLFIN by just using what pkg-config --cflags --libs dolfin gives me.
> >
> > But that doesn't seem to work. I also need to put the place where I
> > have installed PETSc in my LD_LIBRARY_PATH, which I don't want...
> 
> It is because of the 'Requires' line in dolfin.pc:
> 
> Requires: numpy-1 slepc scotch ufc-1 umfpack python-2 petsc gts boost
> libxml-2.0
> 
> You also need the generated pkg-config for petsc, scotch, etc. to be
> present in PKG_CONFIG_PATH.
> 
> Johannes

So do you mean I also need to call pkg-config --libs petsc when
compiling an application?

That seems strange. If I build an application against a library, I
shouldn't need to know all other packages on which that package
depends.

I think if A depends on B, then I should only need to call
pkg-config --libs A to compile against A. So pkg-config --libs A
must include everything that pkg-config --libs B spits out.

-- 
Anders