On 7/31/19, 4:29 AM, "Rainer Canavan" <rainer.cana...@sevenval.com> wrote:
On Wed, Jul 31, 2019 at 1:39 AM Nigel B. Peck <nigelbp...@gmail.com> wrote:
>>
>> Thanks for the answers, great to have more insight on this.
>>
>> Is this a bug? Shouldn't it set up the linking correctly itself when
>> the library has been specified using `--with-ssl`, as it does for
>> `--with-pcre`? I'm considering submitting a bug report, but only want
>> to do so if it really is.
> 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.
Darryl Baker (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL 60201-3715
darryl.ba...@northwestern.edu
(847) 467-6674
