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

[Garth N. Wells]

On 4 March 2017 at 16:07, Jed Brown <jed at jedbrown.org> wrote:
> "Garth N. Wells" <gnw20 at cam.ac.uk> writes:
>
>> 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).
>
> How do you ensure that you find the correct shared versus static
> libraries?  Does the above really work for static?
>

Yes, as far as I've tested. The complication is that a user code that
links to library A, where library A links to PETSc, needs a
find_package(PETSc) call in the user CMake file. I don't understand
CMake magic, but my limited understanding is that

    target_link_libraries(mylib PUBLIC PETSc::petsc)

creates a mylib.cmake file which has a place holder for PETSc::petsc,
which the application CMake file provides provides
(https://cmake.org/cmake/help/v3.5/manual/cmake-packages.7.html#creating-relocatable-packages).

> In another thread, people are saying that PETSc should write a
> petsc-config.cmake that just passes flags "-L/path/to -lfoo" instead of
> fully-resolved library names (at least for static libraries).
>

Doesn't that make it hard to switch between PETSc versions without
rebuilding? And won't it break relocatable builds?

The 'right' fix for a petsc-config.cmake would be the new-style CMake
imported targets to make things relocatable. I didn't care about any
of this until adding a conda-forge package, where a package is built
on a CI system and life is easier if builds can be relocated.

>> 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 ;)).
>
> I always assume those who use CMake live in a perpetual state of despair. ;-)
>

It takes an optimist.

>>>>> 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?
>
> They *are* in Libs.private.

Sorry, missed it.

Garth

I don't know why Barry added the other
> variable; I'd be happy to remove it.
>
>>> 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