CRYPTO_num_locks error occurs due to two versions of libcurl on Centos 7

Question

I've trying to build some c++ libraries on a virtual Centos 7 distribution. For a reason that I haven't found out this os can't see the /usr/local/lib or /usr/local/lib64 where these libraries are installed as other linux distributions do. So I had to add these folders on /etc/ld.so.conf. Then the c++ linker was able to see these libraries. However when afterwards I gave

 sudo yum update

I got the following message:

/usr/lib64/python2.7/site-packages/pycurl.so: undefined symbol: CRYPTO_num_locks

After searching I found that it was cause due to the existence of two version of libcurl. I gave

ldconfig -v | grep libcurl

And I got the following :

ldconfig: Path `/usr/lib' given more than once
ldconfig: Path `/usr/lib64' given more than once
libcurl.so.4 -> libcurl.so.4.4.0
libcurl.so.4 -> libcurl.so.4.3.0

Meaning that I installed a new version of libcurl and now two versions coexist. When I removed the folder paths from the /etc/ld.so.conf then yum worked fine but c++ linker could not find the c++ libaries that my app needs. I also tried to update the LD_LIBRARY_PATH but I had the same problems.
Is there a way to fix this issue without having reinstall the libraries on new location ? Is it safe to remove the older version?

The ls -lsa /usr/lib64/*curl* gave

 0 lrwxrwxrwx. 1 root root 16 Aug 10 10:19 /usr/lib64/libcurl.so.4 -> libcurl.so.4.3.0  

 428 -rwxr-xr-x. 1 root root 435120 Nov 14 2016 /usr/lib64/libcurl.so.4.3.0 

I tried giving

sudo unlink /usr/lib64/libcurl.so.4 
sudo ln -s /usr/local/lib/libcurl.so.4.4.0 /usr/lib64/libcurl.so.4 

I even gave them as root but every time I give ldconfig I get

   libcurl.so.4 -> libcurl.so.4.3.0 

while before ldconfig gives

  libcurl.so.4 -> /usr/local/lib/libcurl.so.4.4.0

Answer 1

I had this same issue, but I didn't have two versions of curl or pycurl installed on my system. One of my end user software installs, changed the LD_LIBRARY_PATH and it didn't include /usr/lib or /usr/lib64. I tried adding them at the end of the path and I still received the same error. I added them to the front, and no more error. I have to inquire with my end user if there's a legitimate reason they excluded the default libraries from the enviroment variable.

Answer 2

Many issues can cause this problem: undefined symbol: CRYPTO_num_locks.

But we have to figure out why will this happen?

The call chain is as the picture below, the function CRYPTO_num_locks is provided by libcrypto.so which is a part of OpenSSL.

CRYPTO_num_locks was removed since OpenSSL 1.1.0, so either we use the correct upper libraries not to call this function anymore or we can use old libraries providing the function by force.

In my case, I resolved this problem with the later way, find the older version libs of OpenSSL(< 1.1.0, usually located under /lib64), and using LD_PRELOAD to specify them:

LD_PRELOAD=/lib64/libssl.so.1.0.2k:/lib64/libcrypto.so.1.0.2k yum update