Re: [users@httpd] Compiling Apache with Non-System OpenSSL

["Nigel B. Peck" <ni...@gmail.com>]

On Wed, 31 Jul 2019 at 9:14 am, Darryl Philip Baker <
darryl.baker@northwestern.edu> wrote:

> On 7/31/19, 4:29 AM, "Rainer Canavan" <ra...@sevenval.com> 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.
>

Great stuff, thanks, this helps a lot in understanding the options better.

I looked at cmake but it says in README.cmake that the support is
experimental and only intended for windows. This is an area I have a lot to
learn so don’t want to stray from the recommended approach at this point.

Setting up LD_LIBRARY_PATH in the envvars seems the best way to go in my
case then, with the need to avoid a system-wide install. Good to have
understood the options better.

Still don’t get why pcre is found in the location provided but not openssl.
🤷‍♂️


>

Re: [users@httpd] Compiling Apache with Non-System OpenSSL

[William A Rowe Jr <wr...@rowe-clan.net>]

On Wed, Jul 31, 2019 at 7:27 PM Nigel B. Peck <ni...@gmail.com> wrote:

>
> Setting up LD_LIBRARY_PATH in the envvars seems the best way to go in my
> case then, with the need to avoid a system-wide install. Good to have
> understood the options better.
>

w.r.t. Apache httpd, there is an installed script called apachectl. This is
the script you want to modify for additional LD_LIBRARY_PATH's and other
runtime tweaks.


> Still don’t get why pcre is found in the location provided but not
> openssl. 🤷‍♂️
>

Every package does things their own way, but either a pkgconfig description
exists to describe the compile and link time option flags or there might be
{package}-config script to retrieve that info. The apr and httpd projects
use 12 different ways to Sunday to get at this info and it varies from
dependency to dependency. And the details in the pkgconfig flags vary
considerably from package to package and their release to release (and also
tweaked by distribution to add extra surprises.)

So it's probably that pkgconfig for pcre sets up the -R path, while openssl
you are building does not, or httpd failed to interrogate and consume that
pkgconfig input in the openssl case, but did the right thing for pcre.