Как линкер или загрузчик справляются с неработающими программными ссылками для разделяемых библиотек?

Question

У меня одна и та же общая библиотека в трех разных путях в системе. Скажем, пути: PATH1, PATH2 и PATH3.

Имя общей библиотеки: libmylib.so

Теперь, в PATH1, если я заменю libmylib.so неработающей программной ссылкой, он отправляется и ищет в PATH2 библиотеку.

Но в PATH1, если я заменю libmylib.so каким-либо другим текстовым файлом (или каким-либо несвязанным файлом) с именем libmylib.so, то выполнение приложения завершится неудачно, сообщив, что «это не заголовок ELF»

Меня немного смущает поведение? Почему он ищет другие пути в случае разрыва софт-ссылки и не работает в случае неправильного файла. Я ожидал, что он также будет искать в других путях неправильный файл.

Answer 1

Вероятно, просто попробуйте открыть его. Висячая символическая ссылка или ее нет, она выдаст ту же ошибку. Вам нужно было бы сделать тест явно для символической ссылки, если вы хотите сделать что-то другое. Несколько программ ухода.

Answer 2

с некоторым другим текстовым файлом (или каким-либо не связанным файлом) с именем libmylib.so

этот файл не является неработающей мягкой ссылкой, это обычный файл (такой как файл общего объекта должен быть) символьная ссылка - это специальный элемент файловой системы (например, каталог), VFS знает его характер благодаря информации, хранящейся в соответствующем inode, но не по содержимому файла.

Резюме:

• битая символическая ссылка все еще символическая ссылка
• реальный файл с расширением .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

Answer 3

Просто так.Я не знаю ни одного проектного документа, описывающего причину такого поведения, но я думаю, что это так: сломанная мягкая ссылка почти такая же, как «файл не найден», и, следовательно, недостаточно серьезная, чтобы не заслуживать обходного пути.Поврежденная библиотека указывает на более серьезную проблему (повреждение диска, файл был перезаписан), поэтому она заслуживает сообщения об ошибке.

Как только вы решите отобразить сообщение об ошибке, вы также должны прекратить работу программы.В противном случае сообщение об ошибке эффективно добавляется к тому, что программа пишет в stderr;это может быть проанализировано второй программой через канал, который затем может завершиться сбоем или распространить ошибку дальше, пока она не попадет в файл журнала, который не будет считан до нескольких месяцев спустя.