petsc4py fails to configure with my own lapack/blas

Ondrej Certik ondrej at
Thu Jun 4 18:28:24 CDT 2009

On Thu, Jun 4, 2009 at 5:18 PM, Ondrej Certik<ondrej at> wrote:
> On Thu, Jun 4, 2009 at 5:14 PM, Lisandro Dalcin<dalcinl at> wrote:
>> On Thu, Jun 4, 2009 at 7:59 PM, Ondrej Certik <ondrej at> wrote:
>>> On Thu, Jun 4, 2009 at 4:13 PM, Lisandro Dalcin<dalcinl at> wrote:
>>>> This smells to a 32/64 bit libs mismatch, or a g77/g95/gfortran
>>>> mismatch. Addionally, could you try to run 'ldd' on core PETSc libs
>>>> and on the extension module?
>>> So those core PETSc libs are just .a libraries (not dynamic
>>> executables). Could that be a problem?
>> That could be a BIG problem. petsc4py does not "officially" support
>> PETSc builds with static libs, though it could work on some scenarios.
>> Moreover, even if you get it working, you will not be able to use let
>> say slepc4py, or any other C code depending on the PETSc libraries
>> (think of a fast, Cython-implemented Function()/Jacobian() routine for
>> a nonlinear problem solved with SNES).
>> I really recommend you to pass '--with-shared' to PETSc's configure.
> Ah, I didn't know I have to pass it. I thought petsc will do the right
> thing. Let me do it right now and I'll report back.

Ok, so now everything is built as an .so library, but it still fails
in exactly the same way as here:

Here is the ldd on petsc libraries:

$ ldd lib/ =>  (0x00007fff32bfe000) => /usr/lib/ (0x00007fc62a372000) => /usr/lib/ (0x00007fc6298ac000) => /usr/lib/ (0x00007fc62968e000) => /usr/lib/ (0x00007fc62946f000) => /usr/lib/ (0x00007fc628ae8000) => /lib/ (0x00007fc6288e4000) => /usr/lib/ (0x00007fc628641000) => /usr/lib/ (0x00007fc6283f8000) => /usr/lib/ (0x00007fc62818d000) => /lib/ (0x00007fc627f73000) => /lib/ (0x00007fc627d6f000) => /lib/ (0x00007fc627b57000) => /lib/ (0x00007fc62793b000) => /usr/lib/ (0x00007fc627736000) => /usr/lib/ (0x00007fc6274fe000) => /usr/lib/ (0x00007fc627222000) => /lib/ (0x00007fc626f9c000) => /lib/ (0x00007fc626c2a000) => /usr/lib/ (0x00007fc626a0e000) => /usr/lib/ (0x00007fc62677d000)
	/lib64/ (0x00007fc62a9ec000) => /usr/lib/ (0x00007fc62657a000) => /usr/lib/ (0x00007fc626374000)

and here on the

$ ldd lib/python2.5/site-packages/petsc4py/lib/linux-gnu-c-debug/ =>  (0x00007fff899ff000) =>
(0x00007f2881264000) =>
(0x00007f2880ffb000) =>
(0x00007f2880b68000) =>
(0x00007f28808a4000) =>
(0x00007f28802f9000) =>
(0x00007f287ffff000) =>
(0x00007f287fc8f000) => /usr/lib/ (0x00007f287f987000) => /usr/lib/ (0x00007f287f769000) => /usr/lib/ (0x00007f287f54a000) => /usr/lib/ (0x00007f287ebc3000) => /lib/ (0x00007f287e9bf000) => /usr/lib/ (0x00007f287e71c000) => /usr/lib/ (0x00007f287e4d3000) => /usr/lib/ (0x00007f287e268000) => /lib/ (0x00007f287e04e000) => /lib/ (0x00007f287de4a000) => /lib/ (0x00007f287dc32000) => /lib/ (0x00007f287da16000) => /usr/lib/ (0x00007f287d811000) => /usr/lib/ (0x00007f287d5d9000) => /usr/lib/ (0x00007f287d2fd000) => /lib/ (0x00007f287d077000) => /lib/ (0x00007f287cd05000) => /usr/lib/ (0x00007f287c240000) => /usr/lib/ (0x00007f287c023000)
	/lib64/ (0x00007f28818b0000) => /usr/lib/ (0x00007f287bd92000) => /usr/lib/ (0x00007f287bb8f000) => /usr/lib/ (0x00007f287b989000)

I also noticed that the -fPIC flags are now put there several times,
but I guess this can't hurt, that's not a problem for now.


More information about the petsc-users mailing list