<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 10 oct. 2019 à 13:08, DIXON, MARK C. <<a href="mailto:mark.c.dixon@durham.ac.uk">mark.c.dixon@durham.ac.uk</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 10 Oct 2019, Eric Noulard wrote:<br>
...<br>
> No they can't because the maximum size is burried into the binary ELF file,<br>
> that why CMake "reserve" some space with many ";;;" in order to replace<br>
> BUILD_RPATH with INSTALL_RPATH when doing<br>
> 'install'.<br>
<br>
Hi Eric,<br>
<br>
Interesting - any ideas on how big the padding is?<br></blockquote><div><br></div><div><br></div><div>Not sure, but I bet CMake is reserving as much space as needed for the forthcoming INSTALL_RPATH</div><div>(as opposed to BUILD_RPATH) he knows when specified in the CMakeLists.txt</div><div>I you rebuild the concerned from source try configuring it with a stupidly long CMAKE_INSTALL_RPATH<br></div><div>i.e.</div><div><br></div><div>cmake -DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath ....</div><div><br></div><div>Then, you can surely have a look using <font face="times new roman, serif">chrpath -l lib_or_exe.</font><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Note however that you should be able to "delete" RPATH: chrpath -d<br>
> and then rely on LD_LIBRARY_PATH, ld.so.config, etc....<br>
><br>
> The thing I don't quite understand why you need to replace/amend RPATH. In<br>
> my (very personal) use case when I have to integrate third-party software:<br>
<br>
My use case is where:<br>
<br>
- I install some software, made available to others via environment<br>
modules (<a href="http://modules.sourceforge.net/" rel="noreferrer" target="_blank">http://modules.sourceforge.net/</a>).<br>
<br>
- The installed software is dynamically linked to other libraries, also<br>
installed via environment modules.<br>
<br>
- I don't want to make people load modules for prerequisite libraries<br>
(and prerequisites for the prerequisites...) to use the software.<br></blockquote><div><br></div><div><br></div><div>ok I see, I did use modules a long time ago on some now oldish supercomputer</div><div>in order to play with various compilers of library versions.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
A complication is that I end up having to build lots of copies of the same <br>
software but built with different prerequisites... so it has to be <br>
automated on top of the upstream project's build system.<br>
<br>
For applications using libraries, I've tended to use wrapper scripts as it <br>
means fewer arguments with build systems. But for libraries using <br>
libraries, rpath's the only real option.<br></blockquote><div><br></div><div>No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?</div><div>Removing rpath is easy; chrpath -d <font face="times new roman, serif">lib_or_exe</font></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My rpath can get quite long.<br></blockquote><div><br></div><div>Yes now I see why, depending on the number of prerequisite you have and how many</div><div>modules are loaded.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
...<br>
> If the developers of the software you are using have chosen in their CMake<br>
> build-system to define an install RPATH your only safe bet<br>
> is probably to build & install the software at your favorite location or<br>
> propose an upstream patch for supporting unspecified RPATH.<br>
><br>
> But may be I miss something in your use case?<br>
<br>
I guess I should be proposing upstream patches but, there are so many <br>
software projects to do this for, it has always been simpler to carry <br>
forward a small patch or patches. Perhaps I should be a better citizen.<br></blockquote><div><br></div><div>It may not be tractable to file dozen of upstream patch and wait for feedback</div><div>but in the case the build system does not offer a way to chose install rpath content I think you are stucked</div><div>(beside remove rpath).</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In this case, what feels easiest is to keep a patch commenting out the <br>
developer's RPATH definition in CMakeLists.txt, identified by Jakub <br>
earlier.<br></blockquote><div><br></div><div>Yes I agree. However I my hypothesis of space reservation in RPATH by cmake is write</div><div>you may want to replace with something that fits your needs and not simply commenting it out.</div><div>Or may be commenting it out and specify CMAKE_INSTALL_RPATH on the command line:</div><div><br></div><div><font face="times new roman, serif">cmake -DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath ....<br></font></div><div><a href="https://cmake.org/cmake/help/v3.15/variable/CMAKE_INSTALL_RPATH.html">https://cmake.org/cmake/help/v3.15/variable/CMAKE_INSTALL_RPATH.html</a><br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div></div>