Как уже упоминалось, статическое связывание является одним из вариантов.За исключением статического связывания с glibc, с каждым выпуском все больше ломается (извините, никаких ссылок; только мой опыт).
Ваша идея chroot
, вероятно, излишня.
Решение для большинства коммерческих продуктовЯ использую, насколько я могу судить, чтобы сделать их «приложение» сценарием оболочки, который устанавливает LD_LIBRARY_PATH
, а затем запускает фактический исполняемый файл.Что-то вроде этого:
#!/bin/sh
here=`dirname "$0"`
export LD_LIBRARY_PATH="$here"/lib
exec "$here"/bin/my_app "$@"
Затем вы просто копируете копию всех соответствующих файлов .so в lib/
, помещаете свой исполняемый файл в bin/
, помещаете скрипт в .
и отправляетевсе дерево.
(чтобы быть достойным производства, правильно добавьте "$here"/lib
к LD_LIBRARY_PATH
, если оно не пустое и т. д.)
[править, чтобы идти с обновлением]
Я думаю, вы можете быть озадачены тем, что жестко запрограммировано, а что нет.ld-linux-x86-64.so.2
- это сам динамический компоновщик;и вы правы, что его путь жестко запрограммирован в заголовке ELF.Но другие библиотеки не жестко закодированы;их ищет динамический компоновщик, который будет соблюдать LD_LIBRARY_PATH
.
Если вам действительно нужен другой файл ld-linux.so, вместо исправления заголовка ELF, просто запустите сам динамический компоновщик:
/path/to/my-ld-linux.so my_program <args>
Это будет использовать ваш компоновщик вместо того, который указан в заголовке ELF.
Исправление самого исполняемого файла - зло.Пожалуйста, подумайте о бедняке, который должен поддерживать ваши вещи после того, как вы продолжите ... Никто не будет ожидать, что вы взломали заголовок ELF вручную. Кто угодно может прочитать, что делает скрипт оболочки.
Только мои 0,02 доллара.