链接器或加载器如何处理共享库的断开软链接？

我在系统中的三个不同路径中具有相同的共享库。假设路径是PATH1，PATH2 & PATH3。链接器或加载器如何处理共享库的断开软链接？

共享库的名字是libmylib.so

现在，PATH1如果我更换一个破碎的软链接的libmylib.so，它为图书馆进入和搜查的PATH2。

但是，PATH1如果我用其名称为libmylib.so一些其他的文本文件（或一些无关的文件）替换libmylib.so，然后应用程序执行失败，指出“没有一个ELF头”

我有些困惑的行为？为什么它会搜索其他路径以避免软连接断开，并在文件不正确的情况下失败。我期待它也搜索其他路径的不正确的文件。

来源

2011-03-15 Jay

它可能只是试图打开它。悬挂符号链接或不存在，它将返回相同的错误。如果你想做一些不同的事情，你需要明确测试符号链接。很少有节目关心。

来源

2011-03-15 14:43:09 AProgrammer

打开一个悬空的符号链接返回ENOENT，同样的错误作为一个不存在的文件，因此对连接器的悬空符号链接看起来是一样的不存在的文件，它将继续看。一旦找到文件，它会停止搜索。 – bdk 2011-03-15 14:46:03

它只是。我不知道任何描述此行为的原因的设计文档，但我认为是这样的：软链接的断开与“找不到文件”几乎相同，因此不够严重，无法解决问题。损坏的库表示更严重的问题（磁盘损坏，文件被覆盖），因此它应该有错误消息。

一旦您决定显示错误信息，您还必须终止程序。否则，错误消息会被有效地预先写入程序写入stderr的内容;这可能会被第二个程序通过管道进行解析，然后管道可能会失败，或者进一步传播错误，直到它结束于直到几个月后才读取的日志文件。

来源

2011-03-15 14:45:20

与具有libmylib.so

此文件中的名称一些其他的文本文件（或一些无关文件）是不是一个破碎软链接，这仅仅是一个普通文件（如共享对象文件应该是）符号链接是一个特殊的文件系统元素（如目录），VFS知道它的本质，因为信息存储在相应的inode中，但不是因为文件内容。

摘要：

破碎符号链接仍然与符号链接扩展
真正的文件。所以，作为共享对象处理（在这种情况下 - 断）

检查他们的属性（d ， - ，L）：

 
drwxr-xr-x 2 Ibadinov staff 68 18 aoû 15:21 dir 
-rw-r--r-- 1 Ibadinov staff 0 18 aoû 15:21 file 
lrwxr-xr-x 1 Ibadinov staff 4 18 aoû 15:22 link -> file

基本信息：

http://en.wikipedia.org/wiki/Inode

http://en.wikipedia.org/wiki/Symbolic_link#Storage_of_symbolic_links

来源

2011-08-18 12:34:36 Ibadinov

链接器或加载器如何处理共享库的断开软链接？

回答

相关问题