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

Question

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

共享库名称为libmylib.so

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

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

我对这种行为有点困惑？为什么它会在软链断开的情况下搜索其他路径，并在文件不正确时失败。我期待它也搜索其他路径的错误文件。

Answer 1

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

Answer 2

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

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

Answer 3

  

使用其他文本文件（或一些不相关的文件），其名称为libmylib.so

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

摘要：

• 破损的符号链接仍然是符号链接
• 扩展名为.so的真实文件被视为共享对象（在本例中为 - 已损坏）

检查他们的属性（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