链接器或加载器如何处理共享库的损坏软链接？答案

【问题标题】：How does the linker or loader deal with broken soft links for shared libraries?链接器或加载器如何处理共享库的损坏软链接？
【发布时间】：2011-03-15 14:36:54
【问题描述】：

我在系统的三个不同路径中拥有相同的共享库。假设路径是 PATH1、PATH2 和 PATH3。

共享库名称是 libmylib.so

现在，在 PATH1 中，如果我用损坏的软链接替换 libmylib.so，它会在 PATH2 中搜索该库。

但是，在 PATH1 中，如果我将 libmylib.so 替换为名称为 libmylib.so 的其他文本文件（或一些不相关的文件），则应用程序执行将失败并显示“不是 ELF 标头”

我对这种行为有点困惑？为什么它会在软链接损坏的情况下搜索其他路径，而在文件不正确的情况下会失败。我期待它也会搜索其他路径以查找不正确的文件。

【问题讨论】：

标签： c linux linker shared-libraries loader

【解决方案1】：

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

【讨论】：

打开悬空符号链接会返回 ENOENT，与不存在的文件相同的错误，因此对于链接器来说，悬空符号链接看起来与不存在的文件相同，并且会继续查找。一旦找到文件，它就会停止搜索。

【解决方案2】：

确实如此。我不知道任何描述这种行为原因的设计文档，但我认为就是这样：损坏的软链接几乎与“找不到文件”相同，因此不够严重，不值得解决。损坏的库表明存在更严重的问题（磁盘损坏、文件已被覆盖），因此应该显示错误消息。

一旦您决定显示错误消息，您还必须终止程序。否则，错误消息将有效地添加到程序写入stderr 的内容之前；这可能由第二个程序通过管道解析，然后可能会失败，或者进一步传播错误，直到它最终出现在一个日志文件中，直到几个月后才被读取。

【讨论】：

【解决方案3】：

与其他一些名为 libmylib.so 的文本文件（或一些不相关的文件）

这个文件不是断掉的软链接，这只是一个普通的文件（应该是共享对象文件）符号链接是一个特殊的文件系统元素（如目录），VFS 知道它的本质是因为存储在相应的 inode 中的信息，而不是因为文件内容。

总结：

损坏的符号链接仍然是符号链接
扩展名为 .so 的真实文件被视为共享对象（在这种情况下 - 损坏）

查看它们的属性 (d,-,l)：

drwxr-xr-x 2 伊巴迪诺夫员工 68 18 aoû 15:21 dir -rw-r--r-- 1 伊巴迪诺夫员工 0 18 aoû 15:21 文件 lrwxr-xr-x 1 Ibadinov 员工 4 18 aoû 15:22 链接 -> 文件

基本信息：

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

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

【讨论】：