[petsc-dev] Problem with petsc.pc when configured with --with-single-library=0

[Garth N. Wells]

On 4 March 2017 at 15:43, Jed Brown <jed at jedbrown.org> wrote:
> "Garth N. Wells" <gnw20 at cam.ac.uk> writes:
>
>> On 1 March 2017 at 16:22, Jed Brown <jed at jedbrown.org> wrote:
>>> Barry and Garth, should we include RPATH flags in the Libs field of
>>> PETSc.pc?  We normally include them in makefiles because PETSc is often
>>> installed to places that aren't in the search path and environment
>>> variables (LD_LIBRARY_PATH) are evil.
>>>
>>
>> I don't think RPATH should be added - I think it's up to the caller to add it.
>
> But how should the caller know which paths to RPATH?

We're using CMake, which configures this for us. We just search for
the libraries by passing CMake the path and library name. (More
specifically, we're using the new CMake imported target
infrastructure).

Here is a new GNU
> Make interface (the second line is only needed if you want RPATH).
>
> LDFLAGS := $(shell pkg-config --libs-only-L --libs-only-other $(PETSc.pc))
> LDFLAGS += $(patsubst -L%, $(shell pkg-config --variable=ldflag_rpath $(PETSc.pc))%, $(shell pkg-config --libs-only-L $(PETSc.pc)))
>
>> A reason I moved to using the PETSc pkg-config file was to better
>> support relocatable builds on our end (which is help for packaging
>> systems like conda), so I would like it to stay easy.
>
> Of course you could just filter out the RPATH flags coming from PETSc.
>

This would require manual intervention. CMake has a new module for
automatically creating 'imported targets' from pkg-config files (it
doesn't quite work perfectly yet, but those of us who use CMake must
live in hope ;)).

>>> Are you aware of any conventions for handling RPATH in pkg-config?
>>
>> No - from a quick search there is discussion about the place but I
>> couldn't see a clear convention.
>
> I'm now providing a variable ldflag_rpath that is set to "-Wl,-rpath,"
> or equivalent.
>
> One concern I have is that I don't want users of PETSc to require a
> third-party configuration system.  If you have simple code, you should
> be able to write a simple makefile that portably builds PETSc.  We kinda
> have that now, but our makefiles don't play well with others.
>
> This is an example of what I'm producing now.  Any comments?
>

Looks ok to me. Any reason why lapack and blas are not included in Libs.private?

Garth

>
> prefix=/home/jed/usr/petsc-mpich-basic-prefix
> exec_prefix=${prefix}
> includedir=${prefix}/include
> libdir=/home/jed/usr/petsc-mpich-basic-prefix/lib
> ccompiler=/opt/mpich/bin/mpicc
> cflags_extra="-fPIC  -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -fvisibility=hidden -g3"
> cflags_dep="-MMD -MP"
> ldflag_rpath="-Wl,-rpath,"
> fcompiler=/opt/mpich/bin/mpif90
> fflags_extra="-fPIC -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g"
> blaslapacklibs=-llapack -lblas
>
> Name: PETSc
> Description: Library to solve ODEs and algebraic equations
> Version: 3.7.5
> Cflags:  -I/home/jed/petsc/include -I/home/jed/petsc/mpich-basic-prefix/include -I/opt/mpich/include
> Libs: -L${libdir} -lpetsc
> Libs.private: -L/opt/mpich/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1 -llapack -lblas -lX11 -lpthread -lhwloc -lssl -lcrypto -lm -lmpifort -lgfortran -lm -lgfortran -lm -lquadmath -lmpicxx -lstdc++ -lm -ldl -lmpi -lgcc_s -ldl