DOLFIN

How can I specify linker options for PETSc?

Asked by Jonathan Harker

I need to link PETSc against the blas and lapack libraries. The script is able to find the libraries.

-- Checking for package 'BLAS'
-- Found BLAS: /usr/lib64/libblas.so

-- Checking for package 'LAPACK'
-- Found LAPACK: /usr/lib64/liblapack.so

And is able to find PETSc:

-- Checking for package 'PETSc'
-- PETSC_DIR is /vol/apps/system
-- PETSC_ARCH is empty
-- Found petscconf.h
-- PETSc test failed
-- PETSc configured without Cusp support
-- PETSc could not be found. Be sure to set PETSC_DIR and PETSC_ARCH. (missing: PETSC_TEST_RUNS)

But in every single case, CMakeFiles/CMakeError.log contains these exact lines:

Performing C++ SOURCE FILE Test PETSC_TEST_RUNS failed with the following output:
Change Dir: /vol/apps/user/src/dolfin-1.0.0/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/gmake "cmTryCompileExec/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory `/n/oregano.cic.pdx.edu/export/vol-apps/apps-linux-x86_64/user/src/dolfin-1.0.0/build/CMakeFiles/CMakeTmp'
/vol/apps/cmake/bin/cmake -E cmake_progress_report /vol/apps/user/src/dolfin-1.0.0/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec.dir/src.cxx.o
/usr/bin/c++ -DPETSC_TEST_RUNS -fopenmp -I/vol/apps/system/include -I/vol/apps/system/include/mpiuni -o CMakeFiles/cmTryCompileExec.dir/src.cxx.o -c /vol/apps/user/src/dolfin-1.0.0/build/CMakeFiles/CMakeTmp/src.cxx
Linking CXX executable cmTryCompileExec
/vol/apps/cmake/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1
/usr/bin/c++ -DPETSC_TEST_RUNS -fopenmp CMakeFiles/cmTryCompileExec.dir/src.cxx.o -o cmTryCompileExec -rdynamic /vol/apps/system/lib/libpetsc.a

Followed by a couple hundred lines of undefine references to blas and lapack. Now, obviously I need to specify to link against blas and lapack, but how do I do so?

Question information

Language:
English Edit question
Status:
Solved
For:
DOLFIN Edit question
Assignee:
No assignee Edit question
Solved by:
Johannes Ring
Solved:
Last query:
Last reply:
Revision history for this message
Best Johannes Ring (johannr) said : 		#1

Is it possible for you to build shared libraries for PETSc? I think that should fix your problem.

Revision history for this message
Jonathan Harker (jesusaurus) said : 		#2

I don't understand. How does building a shared library solve undefined references?

Revision history for this message
Johannes Ring (johannr) said : 		#3

Because the shared PETSc library will be linked to the BLAS and LAPACK libraries.

Revision history for this message
Jonathan Harker (jesusaurus) said : 		#4

Thanks Johannes Ring, that solved my question.

Revision history for this message
Jason Bacon (jwbacon) said : 		#5

I'm almost done developing a FreeBSD port for FEniCS and I'm running into the same issue with the PETSc test runs. Building shared PETSc libs did not help. I'm guessing that adding "-llapack -lblas" would solve it, but I haven't figured out how to do this. Below is a snippet from CMakeError.log. Before I built the shared PETSc lib, it was showing "/usr/local/petsc/lib/libpetsc.a" in place of "-L/usr/local/petsc/lib -lpetsc -Wl,-rpath,/usr/local/petsc/lib", so it seems to be recognizing the shared lib.

Thanks,

/usr/bin/c++ -O2 -pipe -fno-strict-aliasing -DPETSC_TEST_RUNS -fopenmp C
MakeFiles/cmTryCompileExec.dir/src.cxx.o -o cmTryCompileExec -L/usr/local/pets
c/lib -lpetsc -Wl,-rpath,/usr/local/petsc/lib
/usr/local/petsc/lib/libpetsc.so: undefined reference to `dpttrf_'
/usr/local/petsc/lib/libpetsc.so: undefined reference to `dorgqr_'
/usr/local/petsc/lib/libpetsc.so: undefined reference to `_gfortran_getarg_i4'
/usr/local/petsc/lib/libpetsc.so: undefined reference to `dswap_'

P.S. I'm also working on a pkgsrc package which will be tested on NetBSD, RHEL, and eventually OS X.

Revision history for this message
Jason Bacon (jwbacon) said : 		#6

Never mind, persistence pays:

--- cmake/modules/FindPETSc.cmake.orig 2012-05-22 14:18:36.000000000 -0500
+++ cmake/modules/FindPETSc.cmake 2012-05-22 14:19:02.000000000 -0500
@@ -116,7 +116,7 @@
   set(PETSC_INCLUDE ${PETSC_INCLUDE} ${PETSC_CC_INCLUDES})
   petsc_get_variable(PETSC_LIB_BASIC PETSC_LIB_BASIC)
   petsc_get_variable(PETSC_LIB_DIR PETSC_LIB_DIR)
- set(PETSC_LIB "-L${PETSC_LIB_DIR} ${PETSC_LIB_BASIC}")
+ set(PETSC_LIB "-L${PETSC_LIB_DIR} ${PETSC_LIB_BASIC} -llapack -lblas")

   # Remove temporary Makefile
   file(REMOVE ${petsc_config_makefile})

Revision history for this message
Garth Wells (garth-wells) said : 		#7

On 22 May 2012 17:50, Jason Bacon <email address hidden> wrote:
> Question #194887 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/194887
>
> Jason Bacon posted a new comment:
>
> I'm almost done developing a FreeBSD port for FEniCS and I'm running into the same issue with the PETSc test runs.  Building shared PETSc libs did not help.  I'm guessing that adding "-llapack -lblas" would solve it, but I haven't figured out how to do this.  Below is a snippet from CMakeError.log.  Before I built the shared PETSc lib, it was showing "/usr/local/petsc/lib/libpetsc.a" in place of "-L/usr/local/petsc/lib -lpetsc -Wl,-rpath,/usr/local/petsc/lib", so it seems to be recognizing the shared lib.
>
> Thanks,
>
> /usr/bin/c++    -O2 -pipe -fno-strict-aliasing  -DPETSC_TEST_RUNS  -fopenmp    C
> MakeFiles/cmTryCompileExec.dir/src.cxx.o  -o cmTryCompileExec  -L/usr/local/pets
> c/lib -lpetsc -Wl,-rpath,/usr/local/petsc/lib
> /usr/local/petsc/lib/libpetsc.so: undefined reference to `dpttrf_'
> /usr/local/petsc/lib/libpetsc.so: undefined reference to `dorgqr_'
> /usr/local/petsc/lib/libpetsc.so: undefined reference to `_gfortran_getarg_i4'
> /usr/local/petsc/lib/libpetsc.so: undefined reference to `dswap_'
>
> P.S. I'm also working on a pkgsrc package which will be tested on
> NetBSD, RHEL, and eventually OS X.
>

Great!

Jonathan Underwood has been working on a Fedora package. Maybe that
will relate to a RHEL package (although RHEL can be challenging
because the libraries tend to be old).

Garth

> --
> You received this question notification because you are a member of
> DOLFIN Team, which is an answer contact for DOLFIN.

Revision history for this message
Johannes Ring (johannr) said : 		#8

On Wed, May 23, 2012 at 10:25 AM, Garth Wells
<email address hidden> wrote:
> On 22 May 2012 17:50, Jason Bacon <email address hidden> wrote:
>> P.S. I'm also working on a pkgsrc package which will be tested on
>> NetBSD, RHEL, and eventually OS X.
>>
>
> Great!

Yes, very nice. Please let us know when it is ready so we can add
instructions on this page:

  http://fenicsproject.org/download/contributed_packages.html

Johannes

Revision history for this message
Jason Bacon (jwbacon) said : 		#9

Garth is right about the RHEL packages. They're meant to maintain compatibility for commercial apps for 7 years.

That's why I use pkgsrc to manage our open source software. It has a switch called PREFER_PKGSRC that tells it to install and use the pkgsrc package for everything possible, even if another installation is found. Hence, the RPMs from Yum are irrelevant to us. We can even upgrade the OS underneath our open source collection without rebuilding everything.

Thanks for the tip about the contributed_packages page. I'll post a link there when it's done.

   Jason