Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread DIXON, MARK C.
On Thu, 10 Oct 2019, Eric Noulard wrote: ... > with patchelf is works with an intriguing warning: > warning: working around a Linux kernel bug by creating a hole of 2093056 > bytes in ‘/path/to/executable’ > > which seems to be a resolved issue: > https://github.com/NixOS/patchelf/issues/92 > >

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread DIXON, MARK C.
On Thu, 10 Oct 2019, Eric Noulard wrote: ... > No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case? > Removing rpath is easy; chrpath -d lib_or_exe You could but, to avoid a maintenance headache, you'd normally end up getting the environment module to load any prereq

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Zakrzewski, Jakub
From: Eric Noulard Sent: 10 October 2019 14:43 To: Zakrzewski, Jakub Cc: cmake@cmake.org Subject: Re: [CMake] cmake end user vs. developer rpath handling > So I was wrong, thank you for your honest question Jakub. > I learned something usefull thanks

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Eric Noulard
.@gmail.com> >> *Sent:* 10 October 2019 12:05 >> *To:* DIXON, MARK C. >> *Cc:* cmake@cmake.org >> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling >> >> >> > No they can't because the maximum size is burried into the binary

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Eric Noulard
e@cmake.org > *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling > > > > 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 > B

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Zakrzewski, Jakub
From: CMake on behalf of Eric Noulard Sent: 10 October 2019 12:05 To: DIXON, MARK C. Cc: cmake@cmake.org Subject: [DKIM] Re: [CMake] cm?ake end user vs. developer rpath handling > No they can't because the maximum size is burried into the binary ELF file, >

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Eric Noulard
Le jeu. 10 oct. 2019 à 13:08, DIXON, MARK C. 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

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread DIXON, MARK C.
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

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread Eric Noulard
Le jeu. 10 oct. 2019 à 10:36, DIXON, MARK C. 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

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-10 Thread DIXON, MARK C.
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

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-09 Thread Hendrik Sattler
Am 9. Oktober 2019 08:09:19 MESZ schrieb "Zakrzewski, Jakub" >That "something" seems to be line 257: >set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}") IMHO setting this to something based on CMAKE_INSTALL_PREFIX is rarely a good idea if it can be relative to the runtime

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-09 Thread Aaron Cohen
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? On Wed, Oct 9, 2019 at 11:48 AM DIXON, MARK C. wrote: > On Wed, 9 Oct 2019, Craig Scott wrote: > ... > >>> Is there a way to reliably add to, or at

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-09 Thread DIXON, MARK C.
On Wed, 9 Oct 2019, Craig Scott wrote: ... >>> Is there a way to reliably add to, or at least override, the developer's >>> rpath in any cmake-built software? >> >> Short of editing the build system scripts? I doubt... > > The CMAKE_INSTALL_RPATH variable is used to initialise the INSTALL_RPATH >

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-09 Thread DIXON, MARK C.
On Wed, 9 Oct 2019, Zakrzewski, Jakub wrote: ... > That "something" seems to be line 257: set(CMAKE_INSTALL_RPATH > "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}") There's a second something that's adding boost's library directory. I'm guessing this is maybe coming from my copy of cmake's boost

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-09 Thread Craig Scott
On Wed, Oct 9, 2019 at 5:24 PM Zakrzewski, Jakub < jakub.zakrzew...@scheer-group.com> wrote: > > > From: CMake on behalf of DIXON, MARK C. < > mark.c.di...@durham.ac.uk> > Sent: 08 October 2019 17:25 > To: cmake@cmake.org > Subject: [CMake] cmake end user

Re: [CMake] cmake end user vs. developer rpath handling

2019-10-09 Thread Zakrzewski, Jakub
From: CMake on behalf of DIXON, MARK C. Sent: 08 October 2019 17:25 To: cmake@cmake.org Subject: [CMake] cmake end user vs. developer rpath handling >Sometimes, this does the trick. When it does, I'm very happy: > > cmake -D