55

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.

Guy Avraham
  • 3,482
  • 3
  • 38
  • 50
Rodrigo Gurgel
  • 1,696
  • 2
  • 15
  • 32

6 Answers6

58

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.

Guy Avraham
  • 3,482
  • 3
  • 38
  • 50
Dan Pritts
  • 1,274
  • 16
  • 14
  • did they share the same md5sum result before they're gone? – Rodrigo Gurgel Jul 03 '13 at 18:09
  • It wasn't someone before you. The client installer does this. The fix suggested works. – Avindra Goolcharan Feb 24 '15 at 16:32
  • Yes. As he mentioned i also see identical files. Some one rename *.so to *.so.old and copied *.so from the latest driver same name(libmyodbc5w.so.old, libmyodbc5w.so). This could also lead into this issue. rm libmyodbc5w.so.old resolved the issue. – gubs Jul 01 '16 at 13:02
  • Had the same issue with `libcudnn.so.5`. It's identical to others, but caused ldconfig error. just symlinking fixed it. Any idea why does it happen? – grisevg Sep 26 '16 at 19:32
  • 3
    dumb installer scripts, I guess. – Dan Pritts Sep 28 '16 at 14:18
  • I am having this error with 'libcudnn.so.4' In the same directory there are two other files 'libcudnn.so' and 'libcudnn.so.4.0.7'. They all are identical, but I am not sure which one to remove or which one to symlink. – Mobeen Oct 27 '17 at 01:50
  • I would leave the most specifically named file (4.0.7) as a real file, and make the other two symlinks to that. Do ensure they are all identical before you delete. – Dan Pritts Oct 27 '17 at 15:57
  • 2
    This fix applies to lots of different files (it happens a lot with CUDA related files). Essentially, delete the non-symbolic one and recreate it so it links to the latest version. So in this case `cd` to the directory where the file is found, call `ls -a | grep libexpat`, this will show the `libexpat.so.1.5.2` and `libexpat.so.1`. Call `rm libexpat.so.1; ln -s libexpat.so.1.5.2 libexpat.so.1`. You may need to use `sudo`for this. – JakeCowton Jul 09 '18 at 11:35
9

I simply ran the command below:

export LD_LIBRARY_PATH=/usr/lib/

Now it is working fine.

rghome
  • 8,529
  • 8
  • 43
  • 62
Jeetendra_Nath_Jha
  • 107
  • 1
  • 3
  • 6
    can you add a line or two of explanation regarding this? – kRazzy R Jul 17 '18 at 20:59
  • Worked for me while installing Oracle 19c on RHEL7. The error was "/sbin/ldconfig: /lib64/libsnmp++.so.33 is not a symbolic link" – Anurag Singh Aug 19 '20 at 04:51
  • Why would that be the solution to the symlink problem?? Because if forces the search of a lib into another path, and it won't meet the problem? But the missing symlink (due to a copy for instance) remains... – Déjà vu Sep 09 '22 at 11:42
  • Perhaps because it excludes the path that contains the duplicate files. – Dan Pritts Feb 16 '23 at 19:40
7

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.

Guy Avraham
  • 3,482
  • 3
  • 38
  • 50
Rodrigo Gurgel
  • 1,696
  • 2
  • 15
  • 32
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.

alinsoar
  • 15,386
  • 4
  • 57
  • 74
  • The path already is at: local.conf, its content: /usr/local/lib on ld.so.conf is including every file.conf inside its specif folder: /etc/ld.so.conf.d/*.conf – Rodrigo Gurgel Jul 18 '12 at 13:18
  • are you sure it is processed well ? – alinsoar Jul 18 '12 at 13:19
  • That is one of the possibilies, but it found lib3.so that is exactly on that folder. /usb/local/lib holds {lib1.so, lib2.so, lib3.so} – Rodrigo Gurgel Jul 18 '12 at 13:21
  • 1
    run ldconfig -p | grep lib[[:digit:]][.]so, and check if all work. This is all that I can help you with. – alinsoar Jul 18 '12 at 13:25
  • Thank you, it doesn't appear, the main thing is the non sense error /sbin/ldconfig: /usr/local/lib/ is not a symbolic link for a folder, course it's not a link? ld is waiting a link? why is it waiting? – Rodrigo Gurgel Jul 18 '12 at 13:29
  • If you provide more informations, I can help you. But from what you say, I cannot say more. If it does not appear, that means that you did not configure the linker properly, and have to do what I said in my firstmessage. – alinsoar Jul 18 '12 at 13:40
  • My friend, (as I said in my question), the MAIN thing IS the error message, and this error message happens when I run ldconfig. What more info do you need? – Rodrigo Gurgel Jul 18 '12 at 13:47
  • you can use 'ldconfig' command with this answer like: sudo ldconfig /usr/local/cuda -p – Mr. Handy Dec 27 '16 at 12:59
3

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.

Sanjay Poptani
  • 29
  • 4
0

simple run in shell : sudo apt-get install --reinstall libexpat1
got same problem with libxcb - solved in this way - very fast :)

Maxim Akristiniy
  • 2,121
  • 2
  • 15
  • 20