How do I build an app with 1.1.1 that uses libraries built against 1.0.2?

[Mark Richter]

nm says there are no symbols in libssl or libcrypto.

It also says that libcurl has no symbols.  Does that imply that all libcurl's symbols are already resolved?

Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403


________________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Viktor Dukhovni <openssl-users at dukhovni.org>
Sent: Monday, July 22, 2019 10:46 AM
To: openssl-users at openssl.org
Subject: Re: How do I build an app with 1.1.1 that uses libraries built against 1.0.2?

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.
The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited.