petsc4py fails to configure with my own lapack/blas
Hi, I am trying to build petsc-3.0.0 inside Sage, for which I want it to use Sage's lapack and blas. Here is what I do: ./configure --prefix="$SAGE_LOCAL" --with-blas-lapack-dir="$SAGE_LOCAL/lib" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC" (The -fPIC flags are necessary, otherwise petsc4py fails to build on 64bit when linking with petsc -- that might be another bug) When I execute the above line, I get: ********************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): --------------------------------------------------------------------------------------- You set a value for --with-blas-lapack-dir=<dir>, but /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib cannot be used ********************************************************************************* and a configure.log is attached. I also tried: ./configure --prefix="$SAGE_LOCAL" --with-lapack-lib="$SAGE_LOCAL/lib/liblapack.a" --with-blas-lib="$SAGE_LOCAL/lib/libblas.a" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC" but I got the same result. So as a workaround, I configure it with: ./configure --prefix="$SAGE_LOCAL" --with-blas-lapack-dir="/usr/lib" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC" which works fine, petsc4py also installs fine, but unfortunately it doesn't import: http://code.google.com/p/femhub/issues/detail?id=30 which I suspect is due to the wrong lapack and blas during petsc build (but I may be wrong, maybe it's another bug). Does anyone knows what else I can try to get it to work? Thanks, Ondrej
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 PETSc.so extension module? On Thu, Jun 4, 2009 at 7:00 PM, Ondrej Certik <[email protected]> wrote:
Hi,
I am trying to build petsc-3.0.0 inside Sage, for which I want it to use Sage's lapack and blas.
Here is what I do:
./configure --prefix="$SAGE_LOCAL" --with-blas-lapack-dir="$SAGE_LOCAL/lib" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC"
(The -fPIC flags are necessary, otherwise petsc4py fails to build on 64bit when linking with petsc -- that might be another bug)
When I execute the above line, I get:
********************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): --------------------------------------------------------------------------------------- You set a value for --with-blas-lapack-dir=<dir>, but /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib cannot be used *********************************************************************************
and a configure.log is attached. I also tried:
./configure --prefix="$SAGE_LOCAL" --with-lapack-lib="$SAGE_LOCAL/lib/liblapack.a" --with-blas-lib="$SAGE_LOCAL/lib/libblas.a" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC"
but I got the same result. So as a workaround, I configure it with:
./configure --prefix="$SAGE_LOCAL" --with-blas-lapack-dir="/usr/lib" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC"
which works fine, petsc4py also installs fine, but unfortunately it doesn't import:
http://code.google.com/p/femhub/issues/detail?id=30
which I suspect is due to the wrong lapack and blas during petsc build (but I may be wrong, maybe it's another bug).
Does anyone knows what else I can try to get it to work?
Thanks, Ondrej
-- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
On Thu, Jun 4, 2009 at 4:13 PM, Lisandro Dalcin<[email protected]> 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 PETSc.so extension module?
So those core PETSc libs are just .a libraries (not dynamic executables). Could that be a problem? As to PETSc.so: $ ldd lib/linux-gnu-c-debug/PETSc.so linux-vdso.so.1 => (0x00007fff551ff000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f1b4c0c1000) libcblas.so.3gf => /usr/lib/libcblas.so.3gf (0x00007f1b4bea2000) libf77blas.so.3gf => /usr/lib/libf77blas.so.3gf (0x00007f1b4bc83000) libatlas.so.3gf => /usr/lib/libatlas.so.3gf (0x00007f1b4b2fd000) libdl.so.2 => /lib/libdl.so.2 (0x00007f1b4b0d9000) libmpi.so.0 => /usr/lib/libmpi.so.0 (0x00007f1b4ae36000) libopen-rte.so.0 => /usr/lib/libopen-rte.so.0 (0x00007f1b4abee000) libopen-pal.so.0 => /usr/lib/libopen-pal.so.0 (0x00007f1b4a982000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f1b4a768000) libutil.so.1 => /lib/libutil.so.1 (0x00007f1b4a565000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f1b4a34c000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f1b4a130000) libmpi_f90.so.0 => /usr/lib/libmpi_f90.so.0 (0x00007f1b49f2c000) libmpi_f77.so.0 => /usr/lib/libmpi_f77.so.0 (0x00007f1b49cf3000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f1b49a17000) libm.so.6 => /lib/libm.so.6 (0x00007f1b49792000) libc.so.6 => /lib/libc.so.6 (0x00007f1b4941f000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f1b49203000) /lib64/ld-linux-x86-64.so.2 (0x00007f1b4d0f7000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f1b48fff000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f1b48dfa000) So I don't know... Ondrej
On Thu, Jun 4, 2009 at 7:59 PM, Ondrej Certik <[email protected]> wrote:
On Thu, Jun 4, 2009 at 4:13 PM, Lisandro Dalcin<[email protected]> 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 PETSc.so 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.
As to PETSc.so:
$ ldd lib/linux-gnu-c-debug/PETSc.so linux-vdso.so.1 => (0x00007fff551ff000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f1b4c0c1000) libcblas.so.3gf => /usr/lib/libcblas.so.3gf (0x00007f1b4bea2000) libf77blas.so.3gf => /usr/lib/libf77blas.so.3gf (0x00007f1b4bc83000) libatlas.so.3gf => /usr/lib/libatlas.so.3gf (0x00007f1b4b2fd000) libdl.so.2 => /lib/libdl.so.2 (0x00007f1b4b0d9000) libmpi.so.0 => /usr/lib/libmpi.so.0 (0x00007f1b4ae36000) libopen-rte.so.0 => /usr/lib/libopen-rte.so.0 (0x00007f1b4abee000) libopen-pal.so.0 => /usr/lib/libopen-pal.so.0 (0x00007f1b4a982000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f1b4a768000) libutil.so.1 => /lib/libutil.so.1 (0x00007f1b4a565000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f1b4a34c000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f1b4a130000) libmpi_f90.so.0 => /usr/lib/libmpi_f90.so.0 (0x00007f1b49f2c000) libmpi_f77.so.0 => /usr/lib/libmpi_f77.so.0 (0x00007f1b49cf3000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f1b49a17000) libm.so.6 => /lib/libm.so.6 (0x00007f1b49792000) libc.so.6 => /lib/libc.so.6 (0x00007f1b4941f000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f1b49203000) /lib64/ld-linux-x86-64.so.2 (0x00007f1b4d0f7000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f1b48fff000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f1b48dfa000)
So I don't know...
Ondrej
-- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
On Thu, Jun 4, 2009 at 5:14 PM, Lisandro Dalcin<[email protected]> wrote:
On Thu, Jun 4, 2009 at 7:59 PM, Ondrej Certik <[email protected]> wrote:
On Thu, Jun 4, 2009 at 4:13 PM, Lisandro Dalcin<[email protected]> 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 PETSc.so 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. Ondrej
On Thu, Jun 4, 2009 at 5:18 PM, Ondrej Certik<[email protected]> wrote:
On Thu, Jun 4, 2009 at 5:14 PM, Lisandro Dalcin<[email protected]> wrote:
On Thu, Jun 4, 2009 at 7:59 PM, Ondrej Certik <[email protected]> wrote:
On Thu, Jun 4, 2009 at 4:13 PM, Lisandro Dalcin<[email protected]> 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 PETSc.so 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: http://code.google.com/p/femhub/issues/detail?id=30 Here is the ldd on petsc libraries: $ ldd lib/libpetsc.so linux-vdso.so.1 => (0x00007fff32bfe000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fc62a372000) liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00007fc6298ac000) libcblas.so.3gf => /usr/lib/libcblas.so.3gf (0x00007fc62968e000) libf77blas.so.3gf => /usr/lib/libf77blas.so.3gf (0x00007fc62946f000) libatlas.so.3gf => /usr/lib/libatlas.so.3gf (0x00007fc628ae8000) libdl.so.2 => /lib/libdl.so.2 (0x00007fc6288e4000) libmpi.so.0 => /usr/lib/libmpi.so.0 (0x00007fc628641000) libopen-rte.so.0 => /usr/lib/libopen-rte.so.0 (0x00007fc6283f8000) libopen-pal.so.0 => /usr/lib/libopen-pal.so.0 (0x00007fc62818d000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007fc627f73000) libutil.so.1 => /lib/libutil.so.1 (0x00007fc627d6f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fc627b57000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc62793b000) libmpi_f90.so.0 => /usr/lib/libmpi_f90.so.0 (0x00007fc627736000) libmpi_f77.so.0 => /usr/lib/libmpi_f77.so.0 (0x00007fc6274fe000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007fc627222000) libm.so.6 => /lib/libm.so.6 (0x00007fc626f9c000) libc.so.6 => /lib/libc.so.6 (0x00007fc626c2a000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fc626a0e000) libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007fc62677d000) /lib64/ld-linux-x86-64.so.2 (0x00007fc62a9ec000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fc62657a000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fc626374000) and here on the PETSc.so: $ ldd lib/python2.5/site-packages/petsc4py/lib/linux-gnu-c-debug/PETSc.so linux-vdso.so.1 => (0x00007fff899ff000) libpetscts.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscts.so (0x00007f2881264000) libpetscsnes.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscsnes.so (0x00007f2880ffb000) libpetscksp.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscksp.so (0x00007f2880b68000) libpetscdm.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscdm.so (0x00007f28808a4000) libpetscmat.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscmat.so (0x00007f28802f9000) libpetscvec.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscvec.so (0x00007f287ffff000) libpetsc.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetsc.so (0x00007f287fc8f000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f287f987000) libcblas.so.3gf => /usr/lib/libcblas.so.3gf (0x00007f287f769000) libf77blas.so.3gf => /usr/lib/libf77blas.so.3gf (0x00007f287f54a000) libatlas.so.3gf => /usr/lib/libatlas.so.3gf (0x00007f287ebc3000) libdl.so.2 => /lib/libdl.so.2 (0x00007f287e9bf000) libmpi.so.0 => /usr/lib/libmpi.so.0 (0x00007f287e71c000) libopen-rte.so.0 => /usr/lib/libopen-rte.so.0 (0x00007f287e4d3000) libopen-pal.so.0 => /usr/lib/libopen-pal.so.0 (0x00007f287e268000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f287e04e000) libutil.so.1 => /lib/libutil.so.1 (0x00007f287de4a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f287dc32000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f287da16000) libmpi_f90.so.0 => /usr/lib/libmpi_f90.so.0 (0x00007f287d811000) libmpi_f77.so.0 => /usr/lib/libmpi_f77.so.0 (0x00007f287d5d9000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f287d2fd000) libm.so.6 => /lib/libm.so.6 (0x00007f287d077000) libc.so.6 => /lib/libc.so.6 (0x00007f287cd05000) liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00007f287c240000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f287c023000) /lib64/ld-linux-x86-64.so.2 (0x00007f28818b0000) libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007f287bd92000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f287bb8f000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (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. Ondrej
First of all, what Fortran compilers do you have installed? g77? g95? gfortran? all of them? two of them? just one? This is going to be a real mess for you if more than one is installed. If you want to use the system blas/lapack, then you should use a matching compiler, and this dependency will apply when you build numpy and scipy. At first look, it seems you are using blas/lapack libraries built with g77 ?? But PETSc seems to pick gfortran as Fortran compiler ?? Moreover, libpetsc.so is linked with some f77 and f90 MPI bits... I'm not sure if that's fine... On Thu, Jun 4, 2009 at 8:28 PM, Ondrej Certik <[email protected]> wrote:
On Thu, Jun 4, 2009 at 5:18 PM, Ondrej Certik<[email protected]> wrote:
On Thu, Jun 4, 2009 at 5:14 PM, Lisandro Dalcin<[email protected]> wrote:
On Thu, Jun 4, 2009 at 7:59 PM, Ondrej Certik <[email protected]> wrote:
On Thu, Jun 4, 2009 at 4:13 PM, Lisandro Dalcin<[email protected]> 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 PETSc.so 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:
http://code.google.com/p/femhub/issues/detail?id=30
Here is the ldd on petsc libraries:
$ ldd lib/libpetsc.so linux-vdso.so.1 => (0x00007fff32bfe000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fc62a372000) liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00007fc6298ac000) libcblas.so.3gf => /usr/lib/libcblas.so.3gf (0x00007fc62968e000) libf77blas.so.3gf => /usr/lib/libf77blas.so.3gf (0x00007fc62946f000) libatlas.so.3gf => /usr/lib/libatlas.so.3gf (0x00007fc628ae8000) libdl.so.2 => /lib/libdl.so.2 (0x00007fc6288e4000) libmpi.so.0 => /usr/lib/libmpi.so.0 (0x00007fc628641000) libopen-rte.so.0 => /usr/lib/libopen-rte.so.0 (0x00007fc6283f8000) libopen-pal.so.0 => /usr/lib/libopen-pal.so.0 (0x00007fc62818d000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007fc627f73000) libutil.so.1 => /lib/libutil.so.1 (0x00007fc627d6f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fc627b57000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc62793b000) libmpi_f90.so.0 => /usr/lib/libmpi_f90.so.0 (0x00007fc627736000) libmpi_f77.so.0 => /usr/lib/libmpi_f77.so.0 (0x00007fc6274fe000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007fc627222000) libm.so.6 => /lib/libm.so.6 (0x00007fc626f9c000) libc.so.6 => /lib/libc.so.6 (0x00007fc626c2a000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fc626a0e000) libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007fc62677d000) /lib64/ld-linux-x86-64.so.2 (0x00007fc62a9ec000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fc62657a000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fc626374000)
and here on the PETSc.so:
$ ldd lib/python2.5/site-packages/petsc4py/lib/linux-gnu-c-debug/PETSc.so linux-vdso.so.1 => (0x00007fff899ff000) libpetscts.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscts.so (0x00007f2881264000) libpetscsnes.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscsnes.so (0x00007f2880ffb000) libpetscksp.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscksp.so (0x00007f2880b68000) libpetscdm.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscdm.so (0x00007f28808a4000) libpetscmat.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscmat.so (0x00007f28802f9000) libpetscvec.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetscvec.so (0x00007f287ffff000) libpetsc.so => /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib/libpetsc.so (0x00007f287fc8f000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f287f987000) libcblas.so.3gf => /usr/lib/libcblas.so.3gf (0x00007f287f769000) libf77blas.so.3gf => /usr/lib/libf77blas.so.3gf (0x00007f287f54a000) libatlas.so.3gf => /usr/lib/libatlas.so.3gf (0x00007f287ebc3000) libdl.so.2 => /lib/libdl.so.2 (0x00007f287e9bf000) libmpi.so.0 => /usr/lib/libmpi.so.0 (0x00007f287e71c000) libopen-rte.so.0 => /usr/lib/libopen-rte.so.0 (0x00007f287e4d3000) libopen-pal.so.0 => /usr/lib/libopen-pal.so.0 (0x00007f287e268000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f287e04e000) libutil.so.1 => /lib/libutil.so.1 (0x00007f287de4a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f287dc32000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f287da16000) libmpi_f90.so.0 => /usr/lib/libmpi_f90.so.0 (0x00007f287d811000) libmpi_f77.so.0 => /usr/lib/libmpi_f77.so.0 (0x00007f287d5d9000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f287d2fd000) libm.so.6 => /lib/libm.so.6 (0x00007f287d077000) libc.so.6 => /lib/libc.so.6 (0x00007f287cd05000) liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00007f287c240000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f287c023000) /lib64/ld-linux-x86-64.so.2 (0x00007f28818b0000) libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007f287bd92000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f287bb8f000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (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.
Ondrej
-- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
This is a [email protected] request, I am sending it over there and removing from the petsc-users list. Please respond only to the [email protected] list Back to the original problem using the BLAS/LAPACK you provided. It has nothing to do with petsc4py The FOTRAN compiler your mpif90 is using is gfortran (from the configure.log Driving: /usr/bin/gfortran ) but the Fortran compiler used to build your blas/lapack libraries is g95 (from the log file xerbla.f:(.text+0x1b): undefined reference to `_g95_get_ioparm') You cannot do this. You need to either 1) build your MPI to use g95 or 2) build your BLAS/LAPACK with gfortran then run PETSc's config/configure.py again. Barry Best would be to totally remove g95 from your machine then this kind of problem would not happen. On Jun 4, 2009, at 5:00 PM, Ondrej Certik wrote:
Hi,
I am trying to build petsc-3.0.0 inside Sage, for which I want it to use Sage's lapack and blas.
Here is what I do:
./configure --prefix="$SAGE_LOCAL" --with-blas-lapack-dir="$SAGE_LOCAL/lib" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC"
(The -fPIC flags are necessary, otherwise petsc4py fails to build on 64bit when linking with petsc -- that might be another bug)
When I execute the above line, I get:
********************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): --------------------------------------------------------------------------------------- You set a value for --with-blas-lapack-dir=<dir>, but /home/ondrej/ext/spd-3.4.2spd3-ubuntu-64bit/local/lib cannot be used *********************************************************************************
and a configure.log is attached. I also tried:
./configure --prefix="$SAGE_LOCAL" --with-lapack-lib="$SAGE_LOCAL/lib/liblapack.a" --with-blas-lib="$SAGE_LOCAL/lib/libblas.a" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC"
but I got the same result. So as a workaround, I configure it with:
./configure --prefix="$SAGE_LOCAL" --with-blas-lapack-dir="/usr/lib" --CFLAGS="-fPIC" --CXXFLAGS="-fPIC"
which works fine, petsc4py also installs fine, but unfortunately it doesn't import:
http://code.google.com/p/femhub/issues/detail?id=30
which I suspect is due to the wrong lapack and blas during petsc build (but I may be wrong, maybe it's another bug).
Does anyone knows what else I can try to get it to work?
Thanks, Ondrej <configure.log>
participants (3)
-
Barry Smith -
Lisandro Dalcin -
Ondrej Certik