Как запустить старый двоичный файл в современном дистрибутиве GNU / Linux?

#c #linux #shared-libraries #ld #ldd

#c #linux #совместно используемые библиотеки #ld #ldd

Вопрос:

Я пытаюсь запустить старую программу на C , скомпилированную на CentOS 6, в современном дистрибутиве GNU / Linux (Gentoo Linux). В настоящее время CentOS 6 устарела, как и предлагаемые библиотеки, поэтому необходимо обеспечить рабочую среду для двоичного файла.

Я уже пытался скопировать все необходимые разделяемые библиотеки из CentOS 6, требуемые двоичным файлом, используя ldd команду и некоторый скрипт. Теперь у меня есть каталог со всеми необходимыми библиотеками. Однако, когда я пытаюсь запустить свою программу с помощью LD_LIBRARY_PATH=»каталог с .so-файлами», терминал показывает сообщение

 $ LD_LIBRARY_PATH=`pwd`/lib ./my-program
Inconsistency detected by ld.so: dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL' failed!
 

Так что по какой-то причине он не хочет работать. Без принудительной ссылки на old .so двоичный файл также не запускается (очевидно). У меня нет времени перекомпилировать свою программу на современный Linux или создать ее статическую версию, потому что для этого требуются старые библиотеки, и программа должна работать на нескольких компьютерах, которые я не поддерживаю.

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

Если вы дочитали до этой строки, спасибо за внимание!

Я прилагаю список необходимых библиотек (выходные ldd my-program данные):

 linux-vdso.so.1 =>  (0x00007ffc26b40000)
librfftw.so.2 => /usr/lib64/librfftw.so.2 (0x00007f026f631000)
libfftw.so.2 => /usr/lib64/libfftw.so.2 (0x00007f026f3f8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f026f1f4000)
libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5 (0x00007f026efdf000)
libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5 (0x00007f026eddc000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f026ebbf000)
libxml  -2.6.so.2 => /usr/lib64/libxml  -2.6.so.2 (0x00007f026e99c000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f026e649000)
libglibmm-2.4.so.1 => /usr/lib64/libglibmm-2.4.so.1 (0x00007f026e3f4000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f026e1a8000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f026dfa4000)
librt.so.1 => /lib64/librt.so.1 (0x00007f026dd9c000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f026da85000)
libsigc-2.0.so.0 => /usr/lib64/libsigc-2.0.so.0 (0x00007f026d880000)
libstdc  .so.6 => /usr/lib64/libstdc  .so.6 (0x00007f026d57a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f026d2f6000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f026d0e0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f026cd4c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f026f864000)
libz.so.1 => /lib64/libz.so.1 (0x00007f026cb36000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f026c933000)
 

Комментарии:

1. Установите centos6 в chroot или с docker run centos6 помощью команды запустите двоичный файл. В любом случае, запустите двоичный файл, используя старый интерпретатор. Что — то LD_LIBRARY_PATH=$PWD/lib $PWD/lib/ld-linux-x86-64.so.2 ./my-program случилось .

2. @KamilCuk Большое вам спасибо! Я уже использую контейнер LXD, но мои коллеги не готовы к LXD/ Docker / chroot. Ваше предложение использовать старый компоновщик решило проблему 👍🏻

Ответ №1:

Есть ли надежный способ

Номер: p

Есть ли способ запустить старый двоичный файл в современном Linux без контейнеров или виртуальных машин?

Вы можете запустить программу, используя старый компоновщик и указав путь к библиотеке. Если у вас есть старый системный chroot, вы можете:

 LD_LIBRARY_PATH=$PWD/lib $PWD/lib/ld-linux-x86-64.so.2 ./my-program
 

Но обратите внимание, что если ./my-program затем что-либо будет запущено через fork exec , могут возникнуть проблемы. Вы можете установить PATH местоположение из chroot , но все равно интерпретатор может быть неправильным. Так что это «обычно работает», если это простая программа.

В любом случае, если не с docker или простым chroot , вы можете захотеть посмотреть proot program .