some shared libs in /usr/local/lib aren't found but they are in /usr/lib

Question

I can successfully run an executable using a symlink'd shared library in /usr/lib like so -

sudo ln -s /lib/i386-linux-gnu/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.4

In the interest of making this easier to maintain I'd like to move this to /usr/local/lib -

sudo ln -s /lib/i386-linux-gnu/libcrypto.so.0.9.8 /usr/local/lib/libcrypto.so.4

But my system seems to ignore this specific sym link. /usr/local/lib is in relevant ld.so.conf settings and indeed is included in the output of ldconfig -v.

/usr/local/lib:
        libcrypto.so.0.9.8 -> libcrypto.so.4

My only clue so far is that ldconfig creates an additional sym link back to the actual file name...

/usr/local/lib $ ls -l *so*
lrwxrwxrwx 1 root root 14 Aug 26 22:53 libcrypto.so.0.9.8 -> libcrypto.so.4
lrwxrwxrwx 1 root root 38 Aug 26 22:36 libcrypto.so.4 -> /lib/i386-linux-gnu/libcrypto.so.0.9.8
lrwxrwxrwx 1 root root 49 Aug 26 22:36 libiniparser.so.0 -> /usr/lib/x86_64-linux-gnu/samba/libiniparser.so.0

In the output above, for example, the lib and link to libiniparser.so.0 works perfectly fine whether included in /usr/lib or /usr/local/lib. The simplest explanation would be that ldconfig specifically avoids entries that switch the file name of the library, but that theory doesn't explain why this works from /usr/lib.

Any insight would be appreciated, thanks.

Answer 1

You can add more paths by basically adding another configuration file to /etc/ld.so.conf.d containing the directory paths of your new locations and then either rebuild the cache or reboot. Or you can probably use the /sbin/ldconfig command and do the manipulations that way.