> On Jul 18, 2019, at 4:34 PM, Mark Richter <mrichter@xxxxxxxxxxxxxx> 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.
