Linux libcrypto so 10

openssl upgrade with in-house rpm leads to libcrypto.so.10 not found on CentOS 6.6 x64

We are making a new rpm with openssl 1.0.2f and upgrading to that version. The rpm install completes but there are two lines output during upgrade.

/sbin/ldconfig: /usr/lib64/libssl.so.1.0.2 is not symbolic link /sbin/ldconfig: /usr/lib64/libcrypto.so.1.0.2 is not symbolic link 

After the rpm upgrade, packages are not able to use the new so’s because of missing libcrypto.so.10 and libssl.so.10. These links are not created by the rpm. But here is the kicker — even if I manually create libcrypto.so.10 symlink to the new so in /usr/lib64, the applications do not work.

# ssh root@localhost ssh: /usr/lib64/libcrypto.so.10: version 'libcrypto.so.10' not found (required by ssh) 

/usr/bin/ssh: /usr/lib64/libcrypto.so.10: version `libcrypto.so.10' not found (required by /usr/bin/ssh) linux-vdso.so.1 => (0x00007fffc1da0000) libfipscheck.so.1 => /lib64/libfipscheck.so.1 (0x00007fdf17567000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fdf17348000) libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007fdf16e9b000) libutil.so.1 => /lib64/libutil.so.1 (0x00007fdf16c98000) libz.so.1 => /lib64/libz.so.1 (0x00007fdf16a82000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fdf16868000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fdf16631000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fdf16417000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fdf161d2000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fdf15eeb000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fdf15cbf000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fdf15aba000) libnss3.so => /usr/lib64/libnss3.so (0x00007fdf1577b000) libc.so.6 => /lib64/libc.so.6 (0x00007fdf153e7000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fdf151e2000) libplc4.so => /lib64/libplc4.so (0x00007fdf14fdd000) /lib64/ld-linux-x86-64.so.2 (0x00007fdf179ea000) libfreebl3.so => /lib64/libfreebl3.so (0x00007fdf14dda000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fdf14bce000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fdf149cb000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdf147ae000) libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007fdf14581000) libplds4.so => /lib64/libplds4.so (0x00007fdf1437d000) libnspr4.so => /lib64/libnspr4.so (0x00007fdf1413f000) librt.so.1 => /lib64/librt.so.1 (0x00007fdf13f36000) 

Why are the applications not able to use the new so and how can I fix this manually now and eventually in the rpm ?

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libssl.so.10 and libcrypto.so.10 version not found on ubuntu #345

libssl.so.10 and libcrypto.so.10 version not found on ubuntu #345

Comments

libssl.so.10 and libcrypto.so.10 version not found on ubuntu

Summary

When running mama executables like mamalistenc or mamasubscriberc on Ubuntu 17.10 I got «libssl.so.10: version `libssl.so.10′ not found»

Areas Affected

• MAMAC
• MAMACPP
• MAMADOTNET
• MAMAJNI
• MAMDA
• MAMDACPP
• MAMDADOTNET
• MAMDAJNI
• Visual Studio
• SCons
• Unit Tests
• Examples

Details

Hi All,
I have downloaded openmama-6.2.1.linux.x86_64.tar.gz and I’m trying to play with it on Ubuntu 17.10.
When I run some command like mamalistenc or mamasubscriberc they complain about missing libssl.so.10 and libcrypto.so.10.

When running «./mamasubscriberc -tport sub -m qpid» I got:

Starting Subscriber with: topic: MAMA_TOPIC transport: sub 2018-03-02 16:05:40: mama_loadmamaPayload(): Could not open middleware bridge library [mamaqpidimpl] [libssl.so.10: cannot open shared object file: No such file or directory] Error loading bridge: NO_BRIDGE_IMPL 

I then create symlink for libssl.so.10:

cd /lib/x86_64-linux-gnu sudo ln -s libssl.so.1.0.0 libssl.so.10 

Starting Subscriber with: topic: MAMA_TOPIC transport: sub 2018-03-02 16:08:22: mama_loadmamaPayload(): Could not open middleware bridge library [mamaqpidimpl] [libcrypto.so.10: cannot open shared object file: No such file or directory] Error loading bridge: NO_BRIDGE_IMPL 

I then create symlink for libssl.so.10:

cd /lib/x86_64-linux-gnu sudo ln -s libcrypto.so.1.0.0 libcrypto.so.10 

Starting Subscriber with: topic: MAMA_TOPIC transport: sub 2018-03-02 16:11:29: mama_loadmamaPayload(): Could not open middleware bridge library [mamaqpidimpl] [/lib/x86_64-linux-gnu/libssl.so.10: version `libssl.so.10' not found (required by /home/sravera/Scaricati/mama/mama/lib/libqpid-proton.so.10)] Error loading bridge: NO_BRIDGE_IMPL 

ldd /home/sravera/Scaricati/mama/mama/lib/libqpid-proton.so.10 

before creating symlink for libssl.so.10 and libcrypto.so.10, I got:

 linux-vdso.so.1 => (0x00007ffe72b93000) libssl.so.10 => not found libcrypto.so.10 => not found libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fdcab9c9000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdcab7aa000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdcab5a2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdcab1c2000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdcaafbe000) /lib64/ld-linux-x86-64.so.2 (0x00007fdcabe33000) 

running it after creating both symlinks, I got:

/home/sravera/Scaricati/mama/mama/lib/libqpid-proton.so.10: /lib/x86_64-linux-gnu/libssl.so.10: version `libssl.so.10' not found (required by /home/sravera/Scaricati/mama/mama/lib/libqpid-proton.so.10) /home/sravera/Scaricati/mama/mama/lib/libqpid-proton.so.10: /lib/x86_64-linux-gnu/libcrypto.so.10: version `libcrypto.so.10' not found (required by /home/sravera/Scaricati/mama/mama/lib/libqpid-proton.so.10) linux-vdso.so.1 => (0x00007ffd8711f000) libssl.so.10 => /lib/x86_64-linux-gnu/libssl.so.10 (0x00007fae21cc2000) libcrypto.so.10 => /lib/x86_64-linux-gnu/libcrypto.so.10 (0x00007fae21881000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fae21666000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fae21447000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fae2123f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fae20e5f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fae20c5b000) /lib64/ld-linux-x86-64.so.2 (0x00007fae22179000) 

libcrypto and libssl packages installed on my machine are:

ii libcrypto++-dev 5.6.4-8 amd64 General purpose cryptographic library - C++ development ii libcrypto++6 5.6.4-8 amd64 General purpose cryptographic library - shared library ii libssl-dev:amd64 1.0.2g-1ubuntu13.3 amd64 Secure Sockets Layer toolkit - development files ii libssl-doc 1.0.2g-1ubuntu13.3 all Secure Sockets Layer toolkit - development documentation ii libssl1.0-dev:amd64 1.0.2g-1ubuntu13.3 amd64 Secure Sockets Layer toolkit - metapackage ii libssl1.0.0:amd64 1.0.2g-1ubuntu13.3 amd64 Secure Sockets Layer toolkit - shared libraries 

Have you any suggestion to solve this issue?

The text was updated successfully, but these errors were encountered:

Источник

Debian User Forums

libcrypto.so.10: cannot open shared object file: No such fil

libcrypto.so.10: cannot open shared object file: No such fil

#1 Post by Newbie_on_debian » 2014-05-26 13:37

I am trying to install ODBC driver for Debian arrording to these instructions: https://blog.afoolishmanifesto.com/post . on-debian/

libcrypto.so.10: cannot open shared object file: No such file or directory

Please some help me what could be the cause, I have tried to solve this for 10 hr and counting.

1. $ cd /usr/lib $ sudo ln -s libssl.so.0.9.8 libssl.so.10 $ sudo ln -slibcrypto.so.0.9.8 libcrypto.so.10 2. /usr/local/lib64 to the /etc/ld.so.conf.d/doubango.conf file 3. sudo apt-get update sudo apt-get install libssl1.0.0 libssl-dev cd /lib/x86_64-linux-gnu sudo ln -s libssl.so.1.0.0 libssl.so.10 sudo ln -s libcrypto.so.1.0.0 libcrypto.so.10 4. Sudo apt-get install libssl0.9.8:i386

stevepusser Posts: 12830 Joined: 2009-10-06 05:53 Has thanked: 35 times Been thanked: 48 times

Re: libcrypto.so.10: cannot open shared object file: No such

#2 Post by stevepusser » 2014-05-26 15:08

Are you actually running 64-bit, or running 32-bit?

You can find where the files are actually installed with

Re: libcrypto.so.10: cannot open shared object file: No such

#3 Post by lkraemer » 2014-06-01 12:19

So far, you have created symbolic links at:
1. cd /usr/lib
sudo ln -s libssl.so.0.9.8 libssl.so.10
sudo ln -slibcrypto.so.0.9.8 libcrypto.so.10
2. cd /lib/x86_64-linux-gnu
sudo ln -s libssl.so.1.0.0 libssl.so.10
sudo ln -s libcrypto.so.1.0.0 libcrypto.so.10
3. Be careful if you are trying to mix 32 Bit & 64 Bit packages.
And also installed (or tried to install/re-install) the i386 package libssl0.9.8:i386 My Debian Wheezy defaults to the i386 package already being installed.

I’d try removing the four symbolic links first, and then rebuild them when you know exactly where they need to point.
REF: http://www.cyberciti.biz/faq/unix-creat . n-command/

Now, use these commands to locate what you need for the symbolic links.

apt-cache search --installed libssl1.0.0 

Will show if libssl1.0.0 is installed, or you can use Synaptics to search for installed packages.

Assuming you followed the blog posting you should need to create two symbolic links for:

because of the differences between RHEL and Debian. So, lets use these commands to find what is existing:
(copy & paste to prevent errors, search from / and find all versions)

cd / sudo find . -iname "libcrypto.so.*" sudo find . -iname "libssl.so.*" 

larry@debian:/$ sudo find . -iname «libssl.so.*»
./usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
./usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0
./usr/lib/i386-linux-gnu/libssl.so.1.0.0
./usr/lib/i386-linux-gnu/i586/libssl.so.1.0.0
larry@debian:/$

Notice that the above command gives you the PATH, along with the FILENAME.
Since my system is a 64 Bit install, and I install 64 Bit software, I’d pick the following command for my symbolic link:

cd /usr/lib sudo ln -s x86_64-linux-gnu/libssl.so.1.0.0 libssl.so.10 

I’ll leave the last one for you to solve. (It should be easy to figure out)

When you have found the properly named versions on your system, you will need to create the symbolic links,
then verify again with the command ldd, that all the libraries are found.

ldd lib64/libsqlncli-11.0.so.1790.0 echo $PATH 

larry@debian:/$ echo $PATH
/usr/local/lib:/usr/local/share:/home/larry/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
larry@debian:/$

That should make it functional.

Источник

Solution

As I’m quite familiar with Debian and programming, here is some advice:

• if you have questions about setting up your system, ask on SuperUser and/or (if your question is specific to a Un*x flavour) on Unix&Linux
• when fuddling around with symlinks to shared-libraries, you should have a thorough understanding of what you are doing. these files are named for a reason — and the reason is to protect you (the user of the system) from weird crashes, because an application is using a wrong/incompatible library.
• a tutorial that tells you to do so, should give proper warning and explanation about what you are to do.

So, why are these instructions in the tutorial you are following?

The application you are trying to run, has been linked against libcrypto.so . On the developer machine (that was used to produce the application binary), libcrypto.so was a symlink to libcrypto.so.10 , but this is missing on Debian: maybe because the library has been removed (and replaced by a new and incompatible version), or because Debian uses a different naming scheme as compared to the system that was used to compile the application.

If it is the former, then you cannot solve the issue by using symlinks. You have to get the right library (or the application linked against the correct libraries).

If it is the latter, you may get away with symlinking the expected library name with the correct library files found on your system. (This is assuming that the only difference between the two systems is indeed the so-naming scheme).

So, how to do it?

• first of all, you should find out, against which libraries your application was really linked, and which of these libraries are missing.

 $ ldd /path/to/my/app | grep -i "not found" libfoo.so.10 => not found 

 # cd /usr/local/lib/ # ln -s /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0 libfoo.so.10 

Источник