ldconfig error:"is not a symbolic link" when using Linux loader

Question

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.

Answer 1

I simply ran the command below:

export LD_LIBRARY_PATH=/usr/lib/

Now it is working fine.

Answer 2

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.

Answer 3

Solved, at least at the point of the question.

I searched in the web before asking, and there were no conclusive solution, the reason why this error is: lib1.so and lib2.so are not OK, very probably where not compiled for a 64 bit PC, but for a 32 bits machine otherwise lib3.so is a 64 bits lib. At least that is my hypothesis.

VERY unfortunately ldconfig doesn't give a clean error message informing that it could not load the library, it only pumps:

ldconfig: /folder_where_the_wicked_lib_is/ is not a symbolic link

I solved this when I removed the libs not found by ldd over the binary. Now it's easier that I know where lies the problem.

My ld version: GNU ld version 2.20.51, and I don't know if a most recent version has a better message for its users.

Thanks.

Answer 4

You need to include the path of the libraries inside /etc/ld.so.conf, and rerun ldconfig to upate the list

Other possibility is to include in the env variable LD_LIBRARY_PATH the path to your library, and rerun the executable.

check the symbolic links if they point to a valid library ...

You can add the path directly in /etc/ld.so.conf, without include...

run ldconfig -p to see whether your library is well included in the cache.

Answer 5

I have also faced the same issue, The solution for it is : the file for which you are getting the error is probably a duplicated file of the actual file with another version. So just the removal of a particular file on which errors are thrown can resolve the issue.