Compile 12.2 with specific OpenSSL libraries

Joshua Poehls <joshua@poehls.me> writes:

I'm compiling PG 12.2 (on CentOS 7) and need to ensure that it uses a
specific version of OpenSSL (1.1.1h). I've added what I think are the
appropriate `./configure` flags (see below) and compilation is successful
but when I run `ldd -d initdb` or `readelf` I can see that it linked to a
different version of libcrypto/libssl.

--with-openssl --with-includes=/path/to/ssl/include
--with-libraries=/path/to/ssl/lib

My theory is that even though I'm adding --with-libraries/--with-includes,
the build script is finding and using the version of OpenSSL in /lib64/
because it has higher precedence somewhere.

Linux is generally pretty unfriendly to putting shlibs in nonstandard
places. If you want to do that, you need to add an "rpath" spec to
the calling programs, or set LD_LIBRARY_PATH, or fool around with the
dynamic linker's configuration files. "man ld.so" will get you started.

regards, tom lane

rpath and LD_LIBRARY_PATH are only relevant for the runtime
linking/resolution, right? My concern is that at *compilation time* the
wrong version of OpenSSL is being picked up. Is there a way to see the full
library/header path the compiler is using so that I can verify the path I
specified with --with-headers and --with-libraries is taking precedence
over the system paths?

On Tue, Sep 29, 2020 at 1:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Joshua Poehls <joshua@poehls.me> writes:

I'm compiling PG 12.2 (on CentOS 7) and need to ensure that it uses a
specific version of OpenSSL (1.1.1h). I've added what I think are the
appropriate `./configure` flags (see below) and compilation is successful
but when I run `ldd -d initdb` or `readelf` I can see that it linked to a
different version of libcrypto/libssl.

--with-openssl --with-includes=/path/to/ssl/include
--with-libraries=/path/to/ssl/lib

My theory is that even though I'm adding

--with-libraries/--with-includes,

the build script is finding and using the version of OpenSSL in /lib64/
because it has higher precedence somewhere.

Linux is generally pretty unfriendly to putting shlibs in nonstandard
places. If you want to do that, you need to add an "rpath" spec to
the calling programs, or set LD_LIBRARY_PATH, or fool around with the
dynamic linker's configuration files. "man ld.so" will get you started.

regards, tom lane

--
--
Joshua Poehls
joshua@poehls.me

Joshua Poehls <joshua@poehls.me> writes:

rpath and LD_LIBRARY_PATH are only relevant for the runtime
linking/resolution, right? My concern is that at *compilation time* the
wrong version of OpenSSL is being picked up.

No; --with-libraries will control what's linked against. The problem
you face is that the dynamic linker has its own idea of how to resolve
the library references at runtime. (ldd just reports on what the
dynamic linker would do; there's no trace in the executable file of
exactly which copy of a shlib was linked against.)

regards, tom lane

Thanks, Tom. I really appreciate you taking the time to help me out!

I think I'm good now. I ran `readelf -d libpq.so | grep runpath` and I see
that the path I specified in --with-libraries is present (albeit after my
system path). It also appears the version I expected of libssl is being
used (libssl.so.1.1).

At this point I think it's fairly straightforward to set the rpath to lock
down the runtime linking as you mentioned. Thanks again!

On Tue, Sep 29, 2020 at 1:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Joshua Poehls <joshua@poehls.me> writes:

rpath and LD_LIBRARY_PATH are only relevant for the runtime
linking/resolution, right? My concern is that at *compilation time* the
wrong version of OpenSSL is being picked up.

No; --with-libraries will control what's linked against. The problem
you face is that the dynamic linker has its own idea of how to resolve
the library references at runtime. (ldd just reports on what the
dynamic linker would do; there's no trace in the executable file of
exactly which copy of a shlib was linked against.)

regards, tom lane

--
--
Joshua Poehls
joshua@poehls.me