Subject: [FEniCS-dev] Problem with PCHYPRESetType

From: "Gildo de Almeida Leonel" <[email-masked]>
Date: Thu, 4 Dec 2008 20:40:14 -0200 (BRST)

Hi,

I'm trying to run some demo from fenics but when I type python demo.py I
received this error:

ImportError: /usr/lib/libdolfin.so.0: undefined symbol: PCHYPRESetType

I use the Ubuntu Ubuntu 8.04 - the Hardy Heron. Someone does have this
problem too ? Or know the answer.

Thank's

Gildo A. Leonel

---

From: Jed Brown <[email-masked]>
Date: Thu, 4 Dec 2008 23:48:51 +0100

> ImportError: /usr/lib/libdolfin.so.0: undefined symbol: PCHYPRESetType

I'll take a wild guess: you didn't build PETSc --with-shared and
Dolfin's SCons configuration *still* doesn't use the full link line
provided by PETSc.  One solution is to edit the pkgconfig file so that
the `Libs:' reads exactly like what you get after

  $ cd $PETSC_DIR
  $ make getlinklibs

This will provide you with all the static libraries that are required.
Alternatively, you can just build PETSc with shared libs (probably a
good idea anyway on systems that support it since it will dramatically
reduce the size of binaries).

Jed

---

From: Jed Brown <[email-masked]>
Date: Fri, 5 Dec 2008 00:24:05 +0100

> I'll take a wild guess: you didn't build PETSc --with-shared and

Sorry, I'm wrong (although the pkg-config files still won't link static
libs correctly).  I'm guessing that the petscconf.h header (saying that
Hypre is available) is coming from a different build than the one you
are trying to link against.  Do you by chance have more than one set of
libpetsc*.so hanging around?  Maybe one installed through Apt and also a
custom build with Hypre?  If so, then perhaps the wrong one is getting
picked up by the linker.  It would help if you send the full command
that is failing.

Jed

---

From: Anders Logg <[email-masked]>
Date: Fri, 5 Dec 2008 10:22:57 +0100

On Thu, Dec 04, 2008 at 11:48:51PM +0100, Jed Brown wrote:
> provided by PETSc.

I thought we had come (on more than one occasion) to the conclusion
that we shouldn't do this and that the only option is to build PETSc
--with-shared.

-- 
Anders

> One solution is to edit the pkgconfig file so that

> _______________________________________________
> FEniCS-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/fenics-dev

---

From: Jed Brown <[email-masked]>
Date: Fri, 5 Dec 2008 11:26:22 +0100

> that we shouldn't do this and that the only option is to build PETSc

I must have missed the message where it was resolved.  My
FindPETSc.cmake actually tries linking using a minimal link line and
falls back to the full one if that fails.  This works with both shared
and static libs while respecting the maxim that with shared libs, you
should only specify the interface libraries and not recursive
dependencies.  There are legitimate reasons to support static libraries
even on systems which can use shared libs.

If it's been determined that only shared libs are supported, it would
seem appropriate to display that prominently in the install instructions
and have a configure-time check to see if you can actually link against
the provided libs so that you can give users a useful error message.

Jed

---

From: Anders Logg <[email-masked]>
Date: Fri, 12 Dec 2008 11:31:42 +0100

> the provided libs so that you can give users a useful error message.

I found the thread where this was last discussed (I think):

  http://www.fenics.org/pipermail/dolfin-dev/2008-April/007429.html

In summary:

  Matt: I have said this more than 13 times. That link procedure is Wrong
        Wrong Wrong.

  [lots of more discussion]

  Me:   So then the conclusion must be: build PETSc using
        --with-shared=1 or else it won't work and there is no way for us to
        fix it.

  Matt: This argument is outdated. Now petsc-dev will work equally
        well with shared and static libraries since we install everything to
        the prefix.

I don't have a full grasp of the situation but I know Ilmar and
Johannes struggled to get DOLFIN to compile against the Debian/Ubuntu
packages of for example UMFPACK and BLAS which was problematic when we
included PETSC_TS_LIB since then we would get the libraries built by
PETSc.

-- 
Anders