1

Я пытаюсь использовать разделяемые библиотеки, которые плохо работают с ld-linux-x86-64.so.2, который находится в /lib64. У меня нет прав root, поэтому я не могу изменить файл в /lib64. Есть ли способ, которым я могу сказать моей RHEL5.7 коробке использовать другой ld-linux-x86-64.so.2? Я попытался указать путь к версии, которую мне нужно использовать, внутри $ LD_LIBRARY_PATH, но там это игнорируется.

У меня есть исполняемый файл, который поставляется с некоторыми общими библиотеками. Исполняемый файл в основном работает с библиотеками, которые уже найдены на компьютере, но время от времени происходит сбой и указывает на одну из библиотек, которые я использую из /lib. Когда я добавляю некоторые библиотеки, поставляемые с исполняемым файлом, в мой LD_LIBRARY_PATH, это вызывает ошибки сегментации для простых команд, таких как 'ls' 'cp' 'ldd'. Также появилась версия ld-linux-x86-64.so.2 с этим исполняемым файлом, и он не вызывает ошибку сегмента, когда я запускаю команду ./ld-linux-x86-64.so.2 --list libc.so (или другую библиотеку, которая приводит к сбою команд). Я хотел иметь возможность протестировать с помощью ld-linux-x86-64.so.2, который поставляется в комплекте с программным обеспечением, чтобы убедиться, что он позаботился о проблемах (и не вызвал других), прежде чем идти в ИТ и чтобы они внесли изменения во все коробки, на которых мы будем запускать программное обеспечение. Или, если возможно, встроить эту работу в мой сценарий работы, чтобы мне не пришлось проходить весь процесс запроса на изменение.

Симптом включенного libc.so не очень хорошо работает с ld-linux.so, когда я пытаюсь выполнить команду следующим образом. cp: ошибка перемещения: libc.so.6: символ _dl_tls_get_addr_soft, версия GLIBC_PRIVATE не определена в файле ld-linux-x86-64.so.2 с указанием времени ссылки. Я единственный, кто использует мою машину, но моя компания выиграла ' Вы не можете предоставлять root-доступ пользователям, потому что, как вы настроили сеть, если у вас есть root на одном Linux-боксе, вы получаете его на всех.

2 ответа2

6

Извините за этот "ответ", я попытался добавить это в комментарии к вашему вопросу, но интервал и форматирование ограничены.

ld-linux-x86-64.so.2 является довольно важной частью вашей ОС. На самом деле он запускает каждое (64-битное) динамическое приложение. Это не библиотека, а само приложение, обработчик, который вызывается при запуске приложения.

По сути, когда вы запускаете динамическое приложение, ядро сначала запускает ld-linux.so (или как оно называется для вашего размера, дистрибутива и т.д.). Затем ld-linux.so заглядывает в ваше приложение, видит нужные вам библиотеки, видит любые жестко заданные пути для библиотек (например, rpath), проверяет LD_LIBRARY_PATH, а затем ищет все эти библиотеки, проверяет, соответствуют ли они размерам битов, именам, что там у вас. Затем он собирает все это, загружает их и запускает ваше приложение. Если он не может найти библиотеки, он не запускает ваше приложение.

LD_LIBRARY_PATH не может повлиять на ld-linux.so, потому что он запускается ядром, и ядро не загружает библиотеки, как ld-linux.so, оно просто имеет ту, для которой настроено выполнение. Опять же, не библиотека, поэтому не используйте семантику библиотеки (LD_LIBRARY_PATH), чтобы изменить способ ее вызова. У него есть переменные окружения, которые влияют на его работу - подробности смотрите в man ld-linux.so (кроме LD_LIBRARY_PATH, LD_PRELOAD очень полезен).

Мне было бы очень интересно узнать, в чем ваша проблема. Без обид, но, похоже, это проблема XY. Это опять часть ядра ОС. Если он сломан, ваша ОС будет сломана. Если вы хотите поменять его, вы, вероятно, затронете (читай: ужасно сломайтесь) остальную часть вашей системы. Так как у вас нет root, я предполагаю, что вы не единственный в этом поле, и вы бы разозлили нескольких человек. :)

Что ты пытаешься сделать?

0

Добавление другого ответа, потому что другой ответ был в большей степени речью / разглагольствованием.

Похоже, у вас нет проблемы ld-linux.so, но, скорее всего, проблема несоответствия простой библиотеки. Вероятно, версии - RHEL 5 больше не является текущей версией RHEL, поэтому больше не является передовым, и, в частности, у glibc были проблемы с версиями.

Я бы обернул ваш исполняемый файл простым сценарием оболочки, который установил бы LD_LIBRARY_PATH для ваших специальных библиотек, а затем выполнил бы ваше приложение. Таким образом, ваши новые приложения (ls, cs и т.д.) Не будут затронуты этими новыми библиотеками. В вашем скрипте вы даже можете использовать новый ld-linux.so для запуска вашего приложения в скрипте, если это помогло. Я думаю, что нет, но вы можете проверить это. Таким образом, все изолируется от скрипта, нового исполняемого файла и конкретных библиотек, которые идут с ним.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .