[CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

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

> On Wed, 9 Oct 2019, Aaron Cohen wrote:
>
> > Is it not feasible to just let the build system do whatever it is going
> to
> > and use "chrpath" or "patchelf" to change the rpath after-the-fact?
>
> Thanks for the suggestion, but I need to add directories to the rpath: I
> believe that neither utility allows it to increase in size.
>


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'.

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:

1a) I compile them from source and install them using the install prefix *I
need*. For cmake enabled build
     the RPATH will be updated with the one I need *during install*

2a) I use relocatable binary package (of any kind rpm, deb, or even tar.gz)
for which I know that RPATH are
      relative which can adapt to the location where I put them.
      If I cannot find a relocatable binary package then I go back to 1a).

As noted by Hendrik not every software developer are aware of the need for
relocation so they may bury non-relocatable rpath in their buildsystem.

Note that there is usually 2 options for CMake buildsystem and install
RPATH.
You can either:
 1. set some install RPATH (preferably in a relocatable way using $ORIGIN)
 2. don't specify install RPATH at all and let the final user/integrator
setup LD_LIBRARY_PATH or ld.so.config etc...

This is quite well summarized here:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

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?

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