On Mon, Jul 22, 2019 at 04:50:46PM +0000, Mark Richter wrote:
> We have a RHEL 7 app that links to (at least) libcurl that uses OpenSSL 1.0.2, but our app needs 1.1.1.
>
> I'm not at all sure how to set up our Makefile to handle this.
The libcurl shared library will be looking for "libssl.so.1.0.0"
and "libcrypto.so.1.0.0" with associated symbol versions, assuming
the RHEL 7 OpenSSL libraries in /usr/lib employ symbol versioning.
Under the above assumptions, once you have the "shlib_variant"
OpenSSL built, you can just link:
cc -o application application.o \
-L/opt/openssl1.1 -Wl,-rpath,/opt/openssl1.1/lib -lssl -lcrypto \
-lcurl \
...
With the OpenSSL libraries listed before libcurl, just in case your
linker automatically searches nested dependencies first and ends up
linking application.o against libcurl's choice of OpenSSL libraries.
This works on Debian systems where base system's libssl and libcrypto
have symbol versions.
If, however, the system libssl and libcrypto lack symbol versions,
(do they on RHEL 7?) then libcurl will not be explicitly bound to
the base-system OpenSSL API, and depending on the order in which
libraries are loaded may inadvertently end up with the 1.1.1 symbol
bindings (and then fail).
In that case it may be helpful to list libcurl first, hoping that
it will be loaded first, and resolved against the system OpenSSL,
with the variant OpenSSL for your application loaded second, assuming
that the "dependents of dependents" issue is not a problem. But
at the end of the day, that is probably too fragile, you might
also load more libraries at runtime, and those could end up with
the wrong symbols.
So if your base system's libssl and libcrypto have no symbol versions,
you just have to accept the fact that you're stuck with the system
OpenSSL libraries for better or worse.
--
Viktor.
