Error building app on RHEL 7 with openssl 1.1.1

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Error building app on RHEL 7 with openssl 1.1.1

Mark Richter

This is probably along the same lines as other questions I have hasked.

 

I built the 1.1.1 libraries and installed them in /opt/openssl1.1, then modified the Makefile to include the right –I and -L flags, but I get this error:

 

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

 

What am I missing?

 

Mark Richter | Senior Staff Engineer

SolarFlare Communications, Inc. | www.Solarflare.com
9444 Waples Street, #170, San Diego, CA  92121

Mobile: +1 949-632-8403

Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395

 

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.
Reply | Threaded
Open this post in threaded view
|

Re: Error building app on RHEL 7 with openssl 1.1.1

PGNet Dev-6
On 7/18/19 1:34 PM, Mark Richter wrote:
> This is probably along the same lines as other questions I have hasked.
>
> I built the 1.1.1 libraries and installed them in /opt/openssl1.1, then
> modified the Makefile to include the right –I and -L flags, but I get
> this error:

haven't backtracked through the entire thread, but some of the errors
were familiar, and noticed your comment re: "modified the Makefile" ...

Are you (already) using 'config', & including the options:

./config \
  --prefix=/usr/local/openssl \
  --openssldir=/usr/local/openssl \
  --libdir=lib64 \
  -Wl,-rpath=/usr/local/openssl/lib64 \
  ...

Here, that configure & builds nicely without having to directly mod
Makefile.

Reply | Threaded
Open this post in threaded view
|

Re: Error building app on RHEL 7 with openssl 1.1.1

PGNet Dev-6
On 7/18/19 3:37 PM, Mark Richter wrote:> I use:
 >
 > ./config --prefix=/opt/openssl1.1 --openssldir=/opt/openssl1.1
--libdir=lib no-shared zlib-dynamic

just fyi, the options were simply referring to the linking issue, not an
inclusive list; hence the ellipsis

 > I'm pretty sure I can't just use the defaults you provide because the
app also includes libcurl, among others, which itself uses the "normal"
OpenSSL on RHEL 7, which is 1.0.2 and not compatible with 1.1.1.

sounds like your distribution needs drive your build choices.

fwiw, I build local curl, as well as those 'others', with openssl
1.1.1c, in order to similarly deal with dependencies.

the goal is a consistent openssl1.1.1c-using stack.  I haven't found
depending on the distros for that to be a winning proposition.

i understand it's a deep, dark, rabbit-hole; YMMV.

 > My app needs to use 1.1.1 without interfering with other (shared)
libraries it uses that were built with 1.0.2.  It also needs to have
1.1.1 statically linked because we want to ship to customers that don't
have 1.1.1 installed.  I suppose we could include 1.1.1 in its own
directory as part of our rpm, but I'd rather not.
 >
 > These errors appeared when I tried to link with the static 1.1.1
libraries.
understood.

here, I build nothing statically, and build & include all the
pieces-n-parts of the 1.1.1c-consistent stack for any given app in a
local repo.

as above, you can soon start feeling like you're building your own
distro. which we do, as well ... usually necessarily, but grudgingly.

Reply | Threaded
Open this post in threaded view
|

Re: Error building app on RHEL 7 with openssl 1.1.1

Viktor Dukhovni
In reply to this post by Mark Richter
> On Jul 18, 2019, at 4:34 PM, Mark Richter <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

RE: Error building app on RHEL 7 with openssl 1.1.1

Mark Richter
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 <[hidden email]> On Behalf Of Viktor Dukhovni
Sent: Thursday, July 18, 2019 10:19 PM
To: [hidden email]
Subject: Re: Error building app on RHEL 7 with openssl 1.1.1

> On Jul 18, 2019, at 4:34 PM, Mark Richter <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

RE: Error building app on RHEL 7 with openssl 1.1.1

Mark Richter
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 <[hidden email]> On Behalf Of Mark Richter
Sent: Friday, July 19, 2019 11:04 AM
To: [hidden email]
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 <[hidden email]> On Behalf Of Viktor Dukhovni
Sent: Thursday, July 18, 2019 10:19 PM
To: [hidden email]
Subject: Re: Error building app on RHEL 7 with openssl 1.1.1

> On Jul 18, 2019, at 4:34 PM, Mark Richter <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Error building app on RHEL 7 with openssl 1.1.1

Mark Richter
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 <[hidden email]> on behalf of Mark Richter <[hidden email]>
Sent: Friday, July 19, 2019 3:13 PM
To: [hidden email]
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 <[hidden email]> On Behalf Of Mark Richter
Sent: Friday, July 19, 2019 11:04 AM
To: [hidden email]
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 <[hidden email]> On Behalf Of Viktor Dukhovni
Sent: Thursday, July 18, 2019 10:19 PM
To: [hidden email]
Subject: Re: Error building app on RHEL 7 with openssl 1.1.1

> On Jul 18, 2019, at 4:34 PM, Mark Richter <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Error building app on RHEL 7 with openssl 1.1.1

Jan Just Keijser-2
In reply to this post by Mark Richter
Hi Mark,

On 20/07/19 00:13, Mark Richter wrote:
> 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.

this is not an OpenSSL, but a Curl issue; I just downloaded curl 7.53.6 
(the latest) and tried compiling and linking it against OpenSSL 1.1.1 ;
that took quite some effort, as the curl 'configure' script incorrectly
detects the availability of RAND_egd *and* it assumes that the libraries
are always present in a library <prefix>/lib

However, after fixing those errors , I was able to compile & link
libcurl and curl against OpenSSL 1.1.1 and I was able to verify that
that curl-build can now do TLS 1.3

Also, note that the default built of curl on RHEL/CentOS 7 uses nss, not
openssl.
You can contact me for further details.

HTH,

JJK

PS as for the libcurl symbols: as Viktor said, use  'objdump T libcurl.so.4'

> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Mark Richter
> Sent: Friday, July 19, 2019 11:04 AM
> To: [hidden email]
> 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 <[hidden email]> On Behalf Of Viktor Dukhovni
> Sent: Thursday, July 18, 2019 10:19 PM
> To: [hidden email]
> Subject: Re: Error building app on RHEL 7 with openssl 1.1.1
>
>> On Jul 18, 2019, at 4:34 PM, Mark Richter <[hidden email]> 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.