Thread: Compile 12.2 with specific OpenSSL libraries
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.
How can I force the build to use the version of OpenSSL in the directories I specify and not in the system /lib64/ directory?
--
Joshua Poehls
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 <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