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

I am trying to install ODBC driver for Debian arrording to these instructions: https://blog.afoolishmanifesto.com/posts/install-and-configure-the-ms-odbc-driver-on-debian/

However trying to run:

sqlcmd -S localhost

I get the error

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

What could be the cause?

So far I have tried

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

None of these have helped.

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
```
then find out, whether you have a (hopefully compatible) library on your system. A good place to start is /usr/lib/. but not-so-recently, Debian has started moving the libraries to /usr/lib/<host-triplet>, with <host-triplet> describing a target architecture. You can find out the default value if your application was indeed built for the architecture you are running (e.g. for linux-amd64) you can get the string by running something like:
```
  $ gcc -print-multiarch
```
Imagine you discover that you have /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0.
if you have good reason to believe that this can act as a replacement for libfoo.so.10, you can go make the found library available to your application by means of a symlink, e.g.
```
  # cd /usr/local/lib/
  # ln -s /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0 libfoo.so.10
```
Finally, you might need to refresh the cache of the dynamic linker so it starts using the new library, by running ldconfig as root/superuser.