ldconfig错误:不是一个符号链接。

时间:2021-08-03 16:23:44

When running:

运行时:

    sudo /sbin/ldconfig

the following error appears:

出现以下错误:

    /sbin/ldconfig: /usr/local/lib/ is not a symbolic link

When I run file:

当我运行文件:

    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.

在/usr/local/lib/中有三个我使用的库。我把它们命名为lib1, lib2和lib3。

Now, when I do an ldd on my binary it results:

现在,当我在二进制代码上做ldd时,结果如下:

    lib1.so => not found
    lib2.so => not found
    lib3.so => /usr/local/lib/lib3.so (0x00216000)

But all of then are in the same folder as /usr/local/lib/{lib1,lib2,lib3}.so.

但是所有这些都在相同的文件夹中,例如/usr/local/lib/{lib1,lib2,lib3}。

Every time I run ldconfig, the same error appears:

每次运行ldconfig时,都会出现相同的错误:

/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:

我认为/usr/local/lib应该在/etc/ld. conf.d/中声明两次。相依,但不是:

    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.

ld.so。conf只包括/etc/ld.so.conf.d / *。相依,这*。old没有被处理,它指的是/ usr/local/projecta/lib。

After a time tring I deleted all lib1 and lib2 (at some point I tested it on binary's folder), the same error occurs.

在一次tring之后,我删除了所有lib1和lib2(在某个时候我在二进制文件夹中测试了它),同样的错误发生了。

4 个解决方案

#1


31  

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.

我在Oracle 11R2客户端遇到了这个问题。不知道Oracle安装程序是这样做的还是有人在我到达之前做的。它不是64位vs 32位,都是64位的。

The error was that libexpat.so.1 was not a symbolic link.

错误是libexpatso。1不是一个符号链接。

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.

结果发现有两个相同的文件,libexpat.so.1.5.2和libexpat.so.1。删除违规文件并将其与1.5.2版本的符号链接,导致错误消失。

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.

您可能希望这个众所周知的名称与当前版本是一个符号链接。如果你这样做,就不太可能最终得到一个陈旧的库。

#2


5  

Solved, at least at the point of the question.

解决了,至少在问题的关键。

I searched in the web before asking, an 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 PC, but for a 32 bits machine otherwise lib3.so is a 64 bits lib. At least that is my hipothesis.

我在网上搜索了一下,然后问,一个没有结论性的解决方案,这个错误的原因是:lib1。所以,lib2。所以不太好,很可能不是编译为64个PC,而是一个32位的机器,否则是lib3。64位是lib,至少这是我的hipothesis。

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

很不幸,ldconfig没有给出一个干净的错误消息,告知它不能装载库,它只提供:

ldconfig: /folder_where_the_wicked_lib_is/ is not a symbolic link

ldconfig: /folder_where_the_wicked_lib_is/不是一个符号链接。

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.

我解决了这个问题当我移除ldd没有发现的libs。现在我更容易知道问题的症结所在。

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.

我的ld版本:GNU ld版本2.20.51,我不知道最近的版本是否对它的用户有更好的消息。

Thanks.

谢谢。

#3


2  

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

您需要将库的路径包括在/etc/ld.so中。conf,并重新运行ldconfig以提升列表。

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

其他的可能性是在env变量LD_LIBRARY_PATH中包含路径到您的库,并重新运行可执行文件。

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

检查符号链接,如果它们指向一个有效的库…

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

您可以直接在/etc/ lsd中添加路径。相依,不包括…

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

运行ldconfig -p,以查看您的库是否包含在缓存中。

#4


1  

I simply ran the command below:

我只是简单地运行下面的命令:

export LD_LIBRARY_PATH=/usr/lib/

Now it is working fine.

现在它运行良好。

#1


31  

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.

我在Oracle 11R2客户端遇到了这个问题。不知道Oracle安装程序是这样做的还是有人在我到达之前做的。它不是64位vs 32位,都是64位的。

The error was that libexpat.so.1 was not a symbolic link.

错误是libexpatso。1不是一个符号链接。

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.

结果发现有两个相同的文件,libexpat.so.1.5.2和libexpat.so.1。删除违规文件并将其与1.5.2版本的符号链接,导致错误消失。

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.

您可能希望这个众所周知的名称与当前版本是一个符号链接。如果你这样做,就不太可能最终得到一个陈旧的库。

#2


5  

Solved, at least at the point of the question.

解决了,至少在问题的关键。

I searched in the web before asking, an 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 PC, but for a 32 bits machine otherwise lib3.so is a 64 bits lib. At least that is my hipothesis.

我在网上搜索了一下,然后问,一个没有结论性的解决方案,这个错误的原因是:lib1。所以,lib2。所以不太好,很可能不是编译为64个PC,而是一个32位的机器,否则是lib3。64位是lib,至少这是我的hipothesis。

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

很不幸,ldconfig没有给出一个干净的错误消息,告知它不能装载库,它只提供:

ldconfig: /folder_where_the_wicked_lib_is/ is not a symbolic link

ldconfig: /folder_where_the_wicked_lib_is/不是一个符号链接。

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.

我解决了这个问题当我移除ldd没有发现的libs。现在我更容易知道问题的症结所在。

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.

我的ld版本:GNU ld版本2.20.51,我不知道最近的版本是否对它的用户有更好的消息。

Thanks.

谢谢。

#3


2  

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

您需要将库的路径包括在/etc/ld.so中。conf,并重新运行ldconfig以提升列表。

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

其他的可能性是在env变量LD_LIBRARY_PATH中包含路径到您的库,并重新运行可执行文件。

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

检查符号链接,如果它们指向一个有效的库…

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

您可以直接在/etc/ lsd中添加路径。相依,不包括…

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

运行ldconfig -p,以查看您的库是否包含在缓存中。

#4


1  

I simply ran the command below:

我只是简单地运行下面的命令:

export LD_LIBRARY_PATH=/usr/lib/

Now it is working fine.

现在它运行良好。