проблема с заменой OpenVZ в том, что библиотек зависят друг от друга (старая проблема "DLL Hell"). Некоторые библиотеки зависит на OpenVZ, и OpenVZ зависит от других библиотек, которые зависят от еще более библиотек и т. д.
в зависимости от того, сколько вам нужно лет, вы можете избежать использования контейнеров, введя "связное подмножество" старых библиотек в каталог, а затем использовать LD_LIBRARY_PATH переменная окружения, указывающая динамический загрузчик на ваш старый библиотеки.
обычно это хорошо работает, если версия libstdc++ и libc в вашей хост-системе (в /lib или /usr/lib)ABI-совместимый С версией, которая использовалась для компиляции и компоновки старой версии OpenCV (и ее зависимостей). К сожалению, в отличие от ядра Linux ABI, libc ABI иногда изменяется, а libstdc++ ABI изменяется относительно часто.
Итак, захват старого двоичного файла OpenCV с нужной вам версией будет примерно этот процесс:
- Try просто старая библиотека 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), ядро Linux ABI стабильный в течение длительного времени. Это значит:
- старые " userspaces "(все, что работает поверх ядро в отличие от внутри него) должно работать на довольно много новых ядер.
- новые userspaces должны работать на более старых ядрах.
на практике это означает, что если вы не используете драйверы 3d-графики или другое специализированное оборудование в своем контейнере, оно должно "просто работать" независимо от разницы в возрасте между контейнерной системой и ядром хоста (до определенного предела; программное обеспечение, скомпилированное для ядра Linux старше 2.6.9 вообще не будет работать на современном ядре, и старше 2.6.0 точно не будет работать.)
это оставляет градацию "минимальных усилий, необходимых" для запуска старых библиотек (или двоичных файлов, которые зависят от старых библиотек), в зависимости от того, сколько лет и насколько глубоко устаревает:
- Minimal: поместите старую версию библиотеки в каталог, установите LD_LIBRARY_PATH и готово.
- Типичный (используется со многими несвободными играми и программами): Бросаю я старую версию библиотеки и все ее зависимости за исключением libc, установите LD_LIBRARY_PATH и готово.
- обширная замена библиотеки (ошибка; может не работать): удалите старую версию библиотеки libstdc++, libc, libdl и все ее зависимости в каталог, установите LD_LIBRARY_PATH, и все готово.
- контейнеры: установите полную базовую систему для другой, более старой ОС поверх ядра хоста, не запуская ее виртуализация (вы все еще используете только одну копию ядра Linux). быстро, но занимает несколько гигов дискового пространства. очень совместим практически со всем, что вы можете бросить на него (в том числе древних дистрибутивов).
- виртуальные машины: может работать что угодно, даже не Linux операционные системы, и совместимость не является проблемой, пока программное обеспечение гостевой ОС работает на том же процессоре, как ваше оборудование работает.
Komp
3454
