ConfD - libcrypto dependencies

Hi,
I’m using ConfD Basic version 6.2 on RHEL7.2 with OpenSSL version 1.0.1e-fips.

Please guide for below receiving error:
cannot dynamically link with libcrypto shared library

Thanks

Please refer to this other posting at Using a different version of OpenSSL for the possible solution to your problem.

You can also check Cannot dynamically link with libcrypto shared library

I am building with ConfD 7.1.1 which was just released. I have also tried with 7.1. Either way, I am experiencing a problem with OpenSSL.
I am having difficulty getting ConfD to recognize the installed version of libcrypto. From OpenSSL, I have libcrypto.so.1.0.2k installed. However, I am getting errors in my mock build stating that ConfD requires libcrypto.so.1.0.0.

I have examined the directions given in the links above, and I have followed the README file in libconfd, particularly the part about “Building the crypto interface module”. Is this the correct order to use the make targets in order to get libconfd to use the installed version of OpenSSL?

make crypto
make install_crypto
make
make install

That is what I am doing, and all the steps succeed, but ConfD still seems to be looking for libcrypto.so.1.0.0 when I build against it.

The libconfd’s README makes some mention of using LDDRV_FLAGS instead of LDSHARED_FLAGS, but doesn’t give much guidance on what conditions that change would be required. So far, we don’t use either of those flags in our build.

Thank you.

The quick and simple solution:
$ sudo ln -s libcrypto.so.1.0.0 libcrypto.so.1.0.2k
Edit: should of course have been:

$ sudo ln -s libcrypto.so.1.0.2k libcrypto.so.1.0.0

And even better, see @per 's suggestion below.

$ sudo ln -s libcrypto.so.1.0.0 libcrypto.so.1.0.2k

Thanks Conny. I had tried the symlink trick as well, as it was referenced in one of the earlier posts. In my case, it would be the reverse, since libcrypto.so.1.0.2k already exists on my system, as it came with CentOS 7.5. However it didn’t work in my mock environment, even though I have verified that I am creating the link inside the mock chroot. So the problem may be somehow specific to my mock environment and how it is created/destroyed.

It sounds extremely strange that you have a library called libcrypto.so.1.0.2k, unless you created it yourself. If you download the OpenSSL 1.0.2k sources from https://www.openssl.org/ and build it (with shared and threads config options), it will create libcrypto.so.1.0.0. This is because the OpenSSL ABI is compatible across all the 1.0.Nx versions.

Now, this .1.0.0 versioning style is at odds with what Linux/Unix normally uses for shared libraries, and the RHEL/CentOS/Fedora family of distributions have thus chosen to use their own versioning style instead, and call the libcrypto from the OpenSSL 1.0.Nx versions libcrypto.so.10:

$ cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core) 
$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017
$ ldd /bin/openssl
...
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f9e856b2000)
...

Thus the version of @cohult’s “quick and simple solution” for a “normal” CentOS 7 installation would be:

$ sudo ln -s libcrypto.so.10 libcrypto.so.1.0.0

And per above, in this case it is also an entirely appropriate solution - i.e. current versions of ConfD as shipped should (and do) work just fine with libcrypto from OpenSSL 1.0.2k.

Per, thank you for your response. This is what I have in /usr/lib64/

[lib64]$ ls -al libcrypto*
lrwxrwxrwx 1 root root 19 Oct 5 2017 libcrypto.so -> libcrypto.so.1.0.2k
lrwxrwxrwx 1 root root 19 Oct 5 2017 libcrypto.so.10 -> libcrypto.so.1.0.2k
-rwxr-xr-x 1 root root 2512448 Aug 3 2017 libcrypto.so.1.0.2k

Perhaps that is not a correct installation, then. I will confer with our platform team, but they had told me earlier that we are using the OpenSSL that came with CentOS 7.5. Thanks.

“Interesting”:slight_smile: - I have the same in my CentOS install, so I have to retract my “extremely strange” statement. And doing (only) a ln -s libcrypto.so.1.0.2k libcrypto.so.1.0.0 in /usr/lib64 (though I would still recommend ln -s libcrypto.so.10 libcrypto.so.1.0.0) does make it possible for ConfD to start, whereas without it I get the dreaded “cannot dynamically link with libcrypto shared library” error (tried with both 6.7 and 7.1).

Try with a fresh install, i.e. without rebuild from the libconfd tarball, and double-check that you got the symlink right (e.g. ls -lL libcrypto* should show the same thing for all of .so, .so.10, .so.1.0.2k, and (your symlink) .so.1.0.0)

2 Likes

Very useful threads. I have the same blocker issue with Centos 7.
I’ll try the symlink and worst case I can rebuild with my OS-provided crypto as described here:

Will report back with my observations.

so I also have libcrypto.so.1.0.2k.
symlink would not work:

  /opt/confd-basic-7.6/lib/libconfd.so: /lib64/libcrypto.so.1.1:
         version `OPENSSL_1_1_0' not found
         (required by /opt/confd-basic-7.6/lib/libconfd.so)

The instructions in this thread were for ConfD 7.1 which was built with OpenSSL 1.0.0. With ConfD 7.6, ConfD was built with OpenSSL 1.1.1.

You will either need to link to libcrypto.so.1.1.1 in order to use the ConfD 7.6 distribution as is or rebuild libconfd and crypto.so with a different OpenSSL version as described in Chapter 32.13 in the ConfD 7.6 UG.