On 7/31/19, 4:29 AM, "Rainer Canavan" <rainer.canavan@xxxxxxxxxxxx> wrote:
> In my opinion, this is not a bug. autoconf has been handling this the
> way it currently does for decades. Adding an RUN_PATH has the potentially
> unwanted side effect that the binary will preferentially use libraries from
> that directory instead of the system search paths. Additionally, the library
> locations during build time are frequently different from those used at
> run time. If you want your library locations fixed at build time, try cmake.
Sorry to jump in in the middle of this conversation but if you really want to fix the libraries at build time just create a static executable.
I want to mention this approach even though I'm not a fan of it in most cases, especially for complex applications with network connectivity.
Pros:
On every machine it has exactly the libraries it was built with, no matter what or where anything is installed on that system.
(Before the advent of shared libraries, all executables were built this way.)
Cons:
On every machine it has exactly the libraries it was built with, no matter what or where anything is installed on that system.
System patching has no effect. The bugs in the libraries it was built with stay until it is rebuilt with patched static libraries.
The executable itself is bigger both on disk and in memory because it shares no code with any other program on the system.
Building static executables is more useful for diagnostic and security scanning applications where you cannot trust the integrity of the execution environment. As an example, a statically built ps program may show rogue processes where a ps using the in place shared libraries can be blinded to those processes by installing a hacked version of the shared libraries. Though it will not be effective against a kernel level hack.
|