"Garth N. Wells" <[email protected]> writes: > On 4 March 2017 at 15:43, Jed Brown <[email protected]> wrote: >> "Garth N. Wells" <[email protected]> writes: >> >>> On 1 March 2017 at 16:22, Jed Brown <[email protected]> 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?
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).
> 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. ;-)
>>>> 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. 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
signature.asc
Description: PGP signature
