Error building app on RHEL 7 with openssl 1.1.1

Mon Jul 22 16:48:19 UTC 2019

I forgot to mention that this round was on CentOS 7, and the tests fail with or without the variant changes.

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 Mark Richter <mrichter at solarflare.com>
Sent: Friday, July 19, 2019 3:13 PM
To: openssl-users at openssl.org
Subject: RE: Error building app on RHEL 7 with openssl 1.1.1

I figured out the variant issue and built, but the tests are failing - see https://gist.github.com/sf-mrichter/2c5c653b3800708c1a67ba41e4992129.

Still not sure how to link an app to the new ssl that uses libraries that were built with the default.

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Mark Richter
Sent: Friday, July 19, 2019 11:04 AM
To: openssl-users at openssl.org
Subject: RE: Error building app on RHEL 7 with openssl 1.1.1

I've been poking around in the Configurations/* and all the README* files, and on the web, and it is not at all clear to me how/where to specify the inherit_from and shlib_variant options (probably not the right term, but...) or how the resulting libraries are distinguished from the system defaults from the app Makefile and resulting application's point of view, particularly w.r.t. how our app can use 1.1.1 while libraries we also link will use the system default (1.0.2).

Do I copy an existing .conf file to a new name and edit that?  If so, what am I editing from/to?  What's the best way to choose the name for the new file?

How do I get config (or Configure) to use the new conf file, or is that automatic?  If it is automatic, how does that work for "my" platform?

Assuming I use both, do I need to change my source to make use of the new libraries or just my Makefile (and how)?

Our app links to both crypto/ssl and other shared libraries that use the system default.  How do I tell my Makefile which one to use for both our app and the other libraries which need to use the system default openssl crypto/ssl libs?  Do I tack the variant at the front or back end of the -L/-l spec lines?  What about our -I specs (I guess that a -I for the custom 1.1.1 build is all our app needs since we don't care what the other libraries use for compiling)?

As I mentioned, this is all quite new to me.

My apologies if this is as painful for you as it has been for me.

Many, many thanks in advance.  I deeply appreciate all your assistance.

Mark

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Viktor Dukhovni
Sent: Thursday, July 18, 2019 10:19 PM
To: openssl-users at openssl.org
Subject: Re: Error building app on RHEL 7 with openssl 1.1.1

> On Jul 18, 2019, at 4:34 PM, Mark Richter <mrichter at solarflare.com> wrote:
>
> cc -DLOG_LEVEL=LOG_INFO -Wall -Werror -D__ci_driver__ -D__ci_ul_driver__ -D_GNU_SOURCE -DWITH_MCDI_V2 -DWITH_TLS12=0 -DSOLAR_SECURE_VERSION="1.0.3.1020 (3bf2875895d5+ Thu Jul 18 13:27:17 PDT 2019)" -Isrc/include -I/opt/openssl1.1/include -Isrc/tools/mc-comms -Isrc/tools/mc-comms/include -Isrc/emulators/mbedtls/include -I/usr/include/json-c   -g3 -fno-omit-frame-pointer -Isrc/cntlr build/src/cntlr/cntlr.o -o build/bin/cntlr  -Lbuild/lib -L/opt/openssl1.1/lib -Wl,-rpath,/opt/openssl1.1/lib -lsf_core -lcm -lss -lcrypto  -lpci -lcurl -lpthread -lrt -lssl -luuid -ljson-c
> /usr/bin/ld: /opt/openssl1.1/lib/libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
> /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command
> line
> collect2: error: ld returned 1 exit status
> make: *** [build/bin/cntlr] Error 1

While dlopen issue can be resolved by including "-ldl" in your linker options.

If you have not managed to get "shlib_variant" working, the above can't possibly work because the libcurl you're linking with likely expects the OpenSSL 1.0.2 ABI.  If the same symbols are found in your the 1.1.1 library in /opt, libcurl will likely crash.

If however, the /opt/openssl1.1/lib/lib{ssl,crypto} have the shlib_variant SONAMEs and symbol variants, it should work. In that case libcurl will find its symbols in something like:

/usr/lib/libssl.1.0.so

While your application can directly use the OpenSSL 1.1.1 API.
If your use of OpenSSL is entirely via libcurl, then the custom OpenSSL will do you no good, unless you also built a custom libcurl linked against the custom OpenSSL.

Perhaps you're looking for "Nix", or similar where multiple versions of dependents and dependencies coëxist more broadly on the same system (though still likely not multiple versions of the same library in the same address spaces as with the shlib_variant approach), but that's really not RHEL anymore.

--
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.
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.
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.