LINUX.ORG.RU

Запускать приложение для другой версии дистрибутива

 ,


0

1

Есть весьма капризное приложение (точнее, фреймворк), которое собрано под более старую версию Ubuntu, чем у меня. Какие-то части этого фреймворка работают, какие-то ­— нет.

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

Конкретный список того, чего хочется: поставить фреймворк в его родную среду; компилировать исходники с использованием этого фреймворка; пускать скомпилированные приложения в той же среде, что и фреймворк; обеспечить доступ к иксам и даже OpenGL.

Мне понравился подход https://github.com/sdt/docker-raspberry-pi-cross-compiler , там с помощью скрипта-обёртки вызываются команды в контейнере с подмонтированной в него текущей директорией. Напримерм, `rxpc make' и т.д.

Тоже планирую замутить подобное, но может кто-нибудь подскажет альтернативы?



Последнее исправление: SystemD-hater (всего исправлений: 1)

Есть весьма капризное приложение (точнее, фреймворк), которое собрано под более старую версию Ubuntu, чем у меня. Какие-то части этого фреймворка работают, какие-то ­— нет.

Тоже планирую замутить подобное, но может кто-нибудь подскажет альтернативы?

Выкинь это говно.

Что ты конкретно хотел спросить? Да, в докере это можно сделать. Можно перенести сборку в отдельную ОС (возможно, виртуалку), а запускать в докере. Можно все вынести в отдельную ОС. Каких еще ты хочешь альтернатив?

staseg ★★★★★
()
Ответ на: комментарий от staseg

Выкинь это говно.

Чому?

Что ты конкретно хотел спросить?

Как сделать то, что написано в ОП. Без виртуалки, слишком много оверхеда, как мне кажется.

SystemD-hater
() автор топика

Ты очень верно указал Docker в тегах - им и пользуйся

dvrts ★★★
()
Ответ на: комментарий от SystemD-hater

Как сделать то, что написано в ОП. Без виртуалки, слишком много оверхеда, как мне кажется.

Ну так юзай докер, в чем вопрос-то? И имей в виду, что ядро на хосте и в контейнере одно, если поделка завязана на него, может быть ой.

staseg ★★★★★
()
Ответ на: комментарий от staseg

Ядро — хрен с ним. Повязано на версии либ и инклюдов.

SystemD-hater
() автор топика

Я бы сказал, что в данном случае задача, скорее, не для Docker, а для LXC. Потому как требуется не массовый деплой идентичных типовых тупых решений, а один индивидуальный контейнер с целой системой. Незачем тратиться на оверхед из слоёв aufs, думать о персистентности данных и т.п.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Пока попробую docker.

Насчёт деплоя: может, буду с кем-нибудь делиться.

Насчёт «целой системы». Мне нужно не так уж и много: gcc/g++ с libc(++) и их includes, python 2.7, libX11/xcb. Опционально qt4. Вроде всё.

А чем LXC лучше будет?

SystemD-hater
() автор топика
Ответ на: комментарий от SystemD-hater

А чем LXC лучше будет?


LXC и Docker с точки зрения создания виртуальной машины (контейнера, если точнее) весьма близки, но для одиночной индивидуально настроенной системы LXC пододит лучше — более привычная работа (фактически почти не отличается от работы с отдельным компом), меньше ненужных сущностей и отсутствие лишних тонкостей.

Контейнерной виртуализации тред (комментарий)

Docker лучше подходит там, где нужно массовое использование типовых решений.

KRoN73 ★★★★★
()
Ответ на: комментарий от SystemD-hater

Насчёт «целой системы». Мне нужно не так уж и много:

И в том, и в другом случае, придётся в контейнере держать полноценную систему. От хоста остаётся только ядро. Всё остальное, от системы инициализации до прикладного софта в контейнере будет своё.

KRoN73 ★★★★★
()

staseg, dvrts, KRoN73 — всем спасибо, няши. Собрал контейнер. Что раньше не робило, теперь робит. И даже OpenGL c иксами пробросился.

Итоговый размер без Qt и питухона 715 МБ, с Qt и питухоном — 862.

SystemD-hater
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.