Проблема с простой заменой OpenVZ заключается в том, что многие библиотеки зависят друг от друга (старая проблема "DLL Hell"). Некоторые библиотеки зависят от OpenVZ, а OpenVZ зависит от других библиотек, которые зависят от еще большего количества библиотек и т.д.
В зависимости от того, сколько лет вам нужно, вы можете избежать использования контейнеров, введя "связное подмножество" старых библиотек в каталог, а затем использовать переменную среды LD_LIBRARY_PATH чтобы указать динамическому загрузчику на ваших старых библиотеках.
Обычно это хорошо работает, если версия libstdc++ и libc в вашей хост-системе (в /lib или /usr /lib) совместима с ABI с версией, которая использовалась для компиляции и компоновки вашей старой версии OpenCV (и ее зависимостей). К сожалению, в отличие от ABI ядра Linux, ABI libc иногда изменяется, а ABI libstdc++ изменяется относительно часто.
Таким образом, получение старого двоичного файла OpenCV с нужной вам версией приведет примерно к такому процессу:
- Попробуйте только старую библиотеку OpenCV в каталоге LD_LIBRARY_PATH. Если это не сработает, вы получите ошибки об отсутствующих библиотеках (при условии, что зависимости корректно работают с версиями); возьмите эти недостающие библиотеки и поместите их в тот же каталог, что и старый OpenCV. Повторяйте, пока пропавшие ошибки библиотеки не исчезнут.
- Если вы попадаете в точку, в которой вы получаете ошибки поиска символов в libstdc++ или libc, или жалобы на плохую версию glibc, вы безрезультатны, и ваши единственные решения (кроме виртуализации и установки старой версии ОС) ...
Flatpak
http://flatpak.org/ - формат упаковки приложения, который включает все библиотеки зависимостей :)
а также
Контейнеры
Контейнеры - это хороший подход, потому что хорошие контейнерные решения, такие как LXC и LXD, полностью изолируют гостя и даже позволяют гостю запускать свой собственный PID 1 (init-демон). По сути, для запуска любого процесса в Linux определенные вещи должны быть совместимы между тем, что вы уже запускаете, и тем, что вы запускаете, потому что, например, динамический загрузчик (libdl) должен иметь возможность загружать разделяемые библиотеки. Но у контейнеров есть способ полностью изолировать это, поэтому вы можете использовать несовместимые версии libc, libdl и libstdc++ в одном ядре хоста.
Я бы порекомендовал LXD, если вы используете Ubuntu> = 16.04, или OpenVZ, если вы используете старую хост-систему Debian или CentOS/RHEL. К сожалению, LXD не так легко установить в дистрибутивах не-Ubuntu, и OpenVZ (пока) не поддерживает последние дистрибутивы.
Приятно то, что ядро Linux состоит в том, что, за некоторыми исключениями для интерфейсов, специфичных для драйверов (например, Direct Rendering Manager), ABI ядра Linux стабильно долгое время. Это означает:
- Старые "пользовательские пространства" (все, что работает поверх ядра, а не внутри него) должны работать на более новых ядрах.
- Новые пользовательские пространства должны работать на более старых ядрах.
На практике это означает, что если вы не используете в своем контейнере драйверы 3D-графики или другое специализированное оборудование, он должен "Просто работать" независимо от разницы в возрасте между системой контейнера и ядром хоста (до определенного ограничение; программное обеспечение, скомпилированное для ядра Linux старше 2.6.9, обычно не будет работать на современном ядре, а более раннее, чем 2.6.0, определенно не будет работать.)
Это оставляет градацию «минимальных усилий, требуемых» для запуска старых библиотек (или двоичных файлов, которые зависят от старых библиотек), в зависимости от того, сколько лет и насколько глубока старая:
- Минимальный: поместите старую версию библиотеки в каталог, установите LD_LIBRARY_PATH, и все готово.
- Типичный (это используется во многих проприетарных играх и программах): удалите старую версию библиотеки и все ее зависимости, кроме libc, установите LD_LIBRARY_PATH, и все готово.
- Обширная замена библиотеки (глючная; может не работать): удалите старую версию библиотеки, libstdc++, libc, libdl и все ее зависимости в каталог, установите LD_LIBRARY_PATH, и все готово.
- Контейнеры: Установите полную базовую систему для другой, более старой ОС поверх ядра вашего хоста без какой-либо виртуализации (вы все еще используете только одну копию ядра Linux). Быстро, но занимает несколько гигабайт дискового пространства. Чрезвычайно совместим практически со всем, что вы можете на него бросить (включая древние дистрибутивы).
- Виртуальные машины. Может запускать что угодно, даже не-ОС Linux, и совместимость не имеет значения, если программное обеспечение гостевой ОС работает на том же процессоре, что и ваше оборудование.
