How to help an executable find a shared library? - linux

I'm trying to run RF-TrulyMagical, but it says:
error while loading shared libraries: libSM.so.6: cannot open shared object file: No such file or directory
I've tried re-installing the library and running apt-get update and ldconfig, but nothing's changed. The library is at /lib/x86_64-linux-gnu and that path was already listed (I didn't add it myself) in a file inside the /etc/ld.so.conf.d directory.
Output for ldd RF-TrulyMagical is:
linux-gate.so.1 (0xf7fa1000)
libSM.so.6 => not found
libICE.so.6 => not found
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf7f6f000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7e25000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7e20000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7e16000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7df7000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7c71000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7b6f000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7b51000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7973000)
/lib/ld-linux.so.2 (0xf7fa2000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7947000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf7943000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf793c000)
libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xf7921000)
Somewhere it said I should install lib32-libsm, but apt-get says Unable to locate package.
I have no idea what to do. Thanks in advance. (I'm running Ubuntu 18.04.1, if that helps)

Might be a simple case of:
apt-get install libsm6:i386

Related

How to fix 'Can't open libmsodbcsql-17.3.so.1.1'

In ubuntu 19.04 when working with Python3 in an anaconda environment with pyodbc 4.0.26 installed I get the Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib '/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.3.so.1.1' : file not found (0) (SQLDriverConnect)")!
Installed msodbcsql17 in ubuntu 19.04 like described here. I tried all the suggestions from here and here. I did the analysis like described here.
With pyodbc 4.0.26, it is possible to check the driver in the anaconda environment with python3 -c 'import pyodbc; print(pyodbc.drivers())' and got ['ODBC Driver 17 for SQL Server'].
After the analysis and the solutions from the links shown above, I still am not able to get a connection to work with MS-SQL and Python3. Please help me!
Edit:
...:~$ ldd /opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.3.so.1.1
linux-vdso.so.1
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2
libcrypto.so.1.0.0 => not found
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
libssl.so.1.0.0 => not found
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
/lib64/ld-linux-x86-64.so.2
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
Also:
~$ sudo locate libcrypto.so.1.0.0
/home/xxx/anaconda3/pkgs/openssl-1.0.2o-h20670df_0/lib/libcrypto.so.1.0.0
/home/xxx/anaconda3/pkgs/openssl-1.0.2p-h14c3975_0/lib/libcrypto.so.1.0.0
/home/xxx/anaconda3/pkgs/openssl-1.0.2p-h470a237_1/lib/libcrypto.so.1.0.0
and:
~$ sudo locate libssl.so.1.0.0
/home/xxx/anaconda3/pkgs/openssl-1.0.2o-h20670df_0/lib/libssl.so.1.0.0
/home/xxx/anaconda3/pkgs/openssl-1.0.2p-h14c3975_0/lib/libssl.so.1.0.0
/home/xxx/anaconda3/pkgs/openssl-1.0.2p-h470a237_1/lib/libssl.so.1.0.0
And I am working in Anaconda environment.
Installing libssl1.0.0 manually in Ubuntu 19.04 solves the problem, maybe with some other tuning I have done before - see the links mentioned in my question above. You can install the old lib in ubuntu 19.04 with wget http://archive.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu6.2_amd64.deb && dpkg -i libssl1.0.0_1.0.2n-1ubuntu6.2_amd64.deb. It will be installed parallel to libssl1.1.
As of 2019-05-22 Microsoft's installation instructions have not been updated to include Ubuntu 19.04. Microsoft has added an entry for 19.04 in the repository, i.e.,
https://packages.microsoft.com/config/ubuntu/19.04/prod.list
but it may not be ready for prime-time. It certainly looks like they need to sort out the libssl dependency for 19.04 since libssl1.0.0 is apparently no longer available
gord#VBox-Xubuntu1904:~$ sudo apt install libssl1.0.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libssl1.0.0 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'libssl1.0.0' has no installation candidate

Error while loading shared libraries: libevent-2.0.so.5

After upgrade ubuntu 16 to 18. I got this error when execute tmux
tmux: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directory
and here's result when I execute ldd $(which tmux)
linux-vdso.so.1 (0x00007ffd9878a000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f5588dfc000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f5588bd2000)
libevent-2.0.so.5 => not found
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f55889b7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f55885c6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5588fff000
libevent-2.0.so.5 => not found
libevent-2.0-5 (xenial-updates) was repacked to compat-libevent2-5_2.0.21-1ubuntu18_amd64.deb : No conflicts with the Ubuntu 18.04 "libevent-2.1-6".
compat-libevent2-5 Provides /usrlib/libevent-2.0.so.5 -> libevent-2.0.so.5.1.9
Download link https://drive.google.com/file/d/1xG1a3GMZuLc1HIRYMP2vythuqjODmN8o/view?usp=sharing
Package install: sudo gdebi Downloads/compat-libevent2-5_2.0.21-1ubuntu18_amd64.deb

Error in libgraph installation :- missing libgraph.so.1 file in fedora 27

./a.out: error while loading shared libraries: libgraph.so.1: cannot open shared object file: No such file or directory.
ldd a.out :-inux-vdso.so.1 (0x00007ffc5bff4000) libgraph.so.1 => not found libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa242377000) libm.so.6 => /lib64/libm.so.6 (0x00007fa242022000) libgccs.so.1 => /lib64/libgccs.so.1 (0x00007fa241e0b000) libc.so.6 => /lib64/libc.so.6 (0x00007fa241a28000) /lib64/ld-linux-x86-64.so.2 (0x00007fa2426fe000).
here i can see that libgraph.so.1 is missing what shall i do further to get that missing file.
I had this problem even with the correct libraries installed.
Try this:
sudo cp /usr/local/lib/libgraph.* /usr/lib
and compile and run again.

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

I am on a fully updated CentOS 6.6 x64 box.
uname -a
Linux localhost.localdomain 2.6.32-573.18.1.el6.x86_64 #1 SMP Tue Feb 9 22:46:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
It is running openssl 1.0.1e
rpm -qa | grep openssl
openssl-1.0.1e-42.el6_7.4.x86_64
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)
ldd however is able to find the so
/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 ?

Failure to load existing library

I'm trying to explain a complex problem, so bear with me.
Say I have these files
/path/build/
/path/build/liba.so
/path/build/liba.so.3 -> liba.so
/path/build/libtest.so
I even have set PATH=/path/build:... (where ... is my normal $PATH).
At some point libtest.so will load liba.so.3 at runtime.
However, liba.so.3 doesn't seem to exist when running code that (successfully) loads libtest.so, and when I ask ldd for help, I get this:
$ ldd /path/build/libtest.so
linux-vdso.so.1 => (0x00007fff24fff000)
liba.so.3 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8fea222000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8fe9f9e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8fe9d88000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8fe9b6a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8fe97c9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8fea767000)
(note the second output line)
How can I figure out what's going wrong? The library is clearly there, but the loader claims it's not.
Is /path/build on your LD_LIBRARY_PATH? The linux dynamic loader looks here for libraries on Linux, after the default locations

Resources