When running:
sudo /sbin/ldconfig
the following error appears:
/sbin/ldconfig: /usr/local/lib/ is not a symbolic link
When I run the file command, the below appears:
file /usr/local/lib/
/usr/local/lib/: directory
Inside /usr/local/lib/ there are three libraries that I use. I'll call them here as lib1, lib2 and lib3.
Now, when I do an ldd on my binary it results:
lib1.so => not found
lib2.so => not found
lib3.so => /usr/local/lib/lib3.so (0x00216000)
But all of them are in the same folder as /usr/local/lib/{lib1,lib2,lib3}.so.
Every time I run ldconfig, the same error appears:
/usr/local/lib/ is not a symbolic link
I thought /usr/local/lib should be declared twice in /etc/ld.conf.d/*.conf, but not:
sudo egrep '\/usr\/local' /etc/ld.so.conf.d/*
projectA.conf.old:/usr/local/projectA/lib
local.conf:/usr/local/lib
ld.so.conf only includes /etc/ld.so.conf.d/*.conf, so this *.old isn't processed, and it refers to /usr/local/projectA/lib.
After a time trying I deleted all lib1 and lib2 (at some point I tested it on binary's folder), the same error occurs.
I ran into this issue with the Oracle 11R2 client. Not sure if the Oracle installer did this or someone did it here before I arrived. It was not 64-bit vs 32-bit, all was 64-bit.
The error was that libexpat.so.1 was not a symbolic link.
It turned out that there were two identical files, libexpat.so.1.5.2 and libexpat.so.1. Removing the offending file and making it a symlink to the 1.5.2 version caused the error to go away.
Makes sense that you'd want the well-known name to be a symlink to the current version. If you do this, it's less likely that you'll end up with a stale library.
---
@rodrigo gurgel asks in the comments if the files had the same checksum, which I presumed was obvious as I had said they were identical. However, it's a good point - if you are doing this you should compare the files to confirm they really are the same. I would not use an MD5 checksum, as MD5 is obsolete. Instead, use SHA-2 or SHA-3, or a simple binary diff.