[CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 13:08, DIXON, MARK C. <mark.c.dixon at durham.ac.uk> a
écrit :

> On Thu, 10 Oct 2019, Eric Noulard wrote:
> ...
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many ";;;" in order to replace
> > BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Hi Eric,
>
> Interesting - any ideas on how big the padding is?
>


Not sure, but I bet CMake is reserving as much space as needed for the
forthcoming INSTALL_RPATH
(as opposed to BUILD_RPATH) he knows when specified in the CMakeLists.txt
I you rebuild the concerned from source try configuring it with a stupidly
long CMAKE_INSTALL_RPATH
i.e.

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath
....

Then, you can surely have a look using  chrpath -l lib_or_exe.


> > Note however that you should be able to "delete" RPATH: chrpath -d
> > and then rely on LD_LIBRARY_PATH, ld.so.config, etc....
> >
> > The thing I don't quite understand why you need to replace/amend RPATH.
> In
> > my (very personal) use case when I have to integrate third-party
> software:
>
> My use case is where:
>
> - I install some software, made available to others via environment
>    modules (http://modules.sourceforge.net/).
>
> - The installed software is dynamically linked to other libraries, also
>    installed via environment modules.
>
> - I don't want to make people load modules for prerequisite libraries
>    (and prerequisites for the prerequisites...) to use the software.
>


ok I see, I did use modules a long time ago on some now oldish supercomputer
in order to play with various compilers of library versions.


>
> A complication is that I end up having to build lots of copies of the same
> software but built with different prerequisites... so it has to be
> automated on top of the upstream project's build system.
>
> For applications using libraries, I've tended to use wrapper scripts as it
> means fewer arguments with build systems. But for libraries using
> libraries, rpath's the only real option.
>

No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
Removing rpath is easy; chrpath -d lib_or_exe


> My rpath can get quite long.
>

Yes now I see why, depending on the number of  prerequisite you have and
how many
modules are loaded.


> ...
> > If the developers of the software you are using have chosen in their
> CMake
> > build-system to define an install RPATH your only safe bet
> > is probably to build & install the software at your favorite location or
> > propose an upstream patch for supporting unspecified RPATH.
> >
> > But may be I miss something in your use case?
>
> I guess I should be proposing upstream patches but, there are so many
> software projects to do this for, it has always been simpler to carry
> forward a small patch or patches. Perhaps I should be a better citizen.
>

It may not be tractable to file dozen of upstream patch and wait for
feedback
but in the case the build system does not offer a way to chose install
rpath content I think you are stucked
(beside remove rpath).


In this case, what feels easiest is to keep a patch commenting out the
> developer's RPATH definition in CMakeLists.txt, identified by Jakub
> earlier.
>

Yes I agree. However I my hypothesis of space reservation in RPATH by cmake
is write
you may want to replace with something that fits your needs and not simply
commenting it out.
Or may be  commenting it out and specify CMAKE_INSTALL_RPATH on the command
line:

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath
....
https://cmake.org/cmake/help/v3.15/variable/CMAKE_INSTALL_RPATH.html

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20191010/d3b134e9/attachment.html>