LINUX.ORG.RU

Реально ли собрать все пакеты для chroot руками?

 , , ,


0

2

Всем привет!

Я делаю маленькое приложение на Qt 5, со статической линковкой под Windows, Linux, FreeBSD, macOS. Базово задачу статической линковки я решил, пусть и немного криво, так как:

  • куча виртуалок для сборки под конкретный environment - по две на каждую ось, кроме macOS (так как там нет i686), если добавить еще и aarch64, то будет вообще катастрофа
  • в одном и том же дистрибутиве Linux на разных архитектурах почему-то линкуется разный набор библиотек, хотя через apt ставилось одно и то же и конфигурация при компиляции Qt одинаковая. Во FreeBSD ситуация еще хуже, там надо руками подбирать версии зависимостей

Я прочитал, что решить эти проблемы поможет использование chroot и дальнейшей кросс-компиляции через него (через передачу sysroot при сборке Qt). Таким образом должно быть можно собрать окружение для Windows, Linux, FreeBSD на одной единственной виртуалке, но есть нюанс: простое копирование директорий /usr/include и /usr/lib из целевых систем мне скорее всего не поможет, т.к. они унаследуют проблемы с зависимостями из оригинальных окружений.

В связи с этим вопрос: можно ли как-то подобрать нужные версии библиотек (xlib, xkbcommon, glibc, etc…) и собрать их вручную, чтобы точно был нужный состав либ и их версии? Или это как-то по-другому делается?

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

Буду очень благодарен за любые подсказки :)

Во FreeBSD ситуация еще хуже, там надо руками подбирать версии зависимостей

Шта? FreeBSD ничем не отличается от линуксов - собирай со статическими либами поставленными из штатного пакетного менеджера и всё.

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

У оригинальных окружений нет проблем с зависимостями, поэтому можно и чрутом.

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

О, я тебе её даже процитирую:

Распространяй свой софт в исходниках.

anonymous
()

Статическая линковка — зло и путь в никуда. В чём сложность линковаться с библиотеками, поставляемыми дистрибутивом?

И да, что используешь в качестве системы сборки?

XMs ★★★★★
()

Не нужно пытаться сделать универсальный дистрибутив, пусть Qt будет использоваться как обычно для той системы, где стоит. Для Windows - тащим с собой dll-ки через windeployqt в Inno Setupе, для Linux - пакуем во Flatpakе или подобном, чтобы избежать «so-hell», для MacOS - через macdeployqt с их слабой линковкой и так сойдёт.

raspopov
()

Базово задачу статической линковки я решил, пусть и немного криво, так как… куча виртуалок для сборки под конкретный environment

На мой взгляд, нормальное решение. Не надо ломать голову, достаточно ли ты изолировал сборочную среду, кае в случае с контейнерами или chroot (но ничего против контейнеров не имею, кого устраивает — на здоровье). Для сборки под винду можно взять реактось, она в виртуалке компактнее, чем даже XP. Я, правда, так делал только для 32-разрядных сборок, 64-разрядные у них экспериментальные.

в одном и том же дистрибутиве Linux на разных архитектурах почему-то линкуется разный набор библиотек

А вот про это можешь поподробнее, какие именно библиотеки фигурируют?

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 2)

Плюсую сборку в докере. Для новичков - самое оно. Следующий шаг - это кросскомпиляция, но chroot для этого не нужен, нужно собрать тулчейн и в его root кросскомпилировать все зависимости.

faq2
()

Глянь как-нить на досуге ZIG компилятор, у него довольно неплохая косс-компиляция C/C++. Авось сможет заменить тебе зоопарк окружений.

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

Статическая линковка позволяет уменьшить размер бинарника и увеличить скоровьи запуска благодаря возможности stripping.

Коеш-коеш, особенно если в зависимостях Qt и у тебя на этот Qt и каждый бинарник раздувается и грузить его с диска нужно заново (и дедупликация ФС работать не будет потому что LTO и выкидываение ненужных символов).

anonymous
()
Ответ на: комментарий от hobbit

Для сборки под винду можно взять реактось, она в виртуалке компактнее, чем даже XP.

Нельзя. Я как-то хотел там протестить кросскомпилированный rust бинарь. Сначала вообще хотел его там собрать, но там даже браузеров рабочих нет - в каталоге приложений допотопные ff и хром, которые не могут открыть ни один сайт (видимо не умеют TLS1.3), и они там не просто так потому что более новые версии не запустятся. А curl не ставит бинарник в %PATH%, я его так и не нашёл. VirtualBox additions поставить нельзя, они убивают систему. Поэтому даже файл передать в систему - боль. В итоге на компиляцию я забил (у rust замечательная кросс-компиляция, поэтому целевая система и не нужна), уж не помню как передал в виртуалку бинарник helloworld и он.. не запустился.

Уж проще, если уж на то пошло, в wine тестить. ReactOS ни для чего не годится.

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

ReactOS ни для чего не годится.

Разумный человек написал бы «я не осилил», «у меня не получилось», на худой конец «для моих целей не подошло». Анонимус с размаху повесил ярлык. Ну и ладно. Почему-то у меня и git, и mingw в реактоси заработали. Раст не пробовал, тем более ТС спрашивал конкретно про Qt/C++.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от raspopov

Для Windows - тащим с собой dll-ки

И для одного exe получаем кучу ненужного мусора. Вот от трёх и выше dll-ки уже выгоднее, да.

для Linux - пакуем во Flatpakе

И чем же Qt во флатпаке лучше статической сборки, если каждый флатпак будет свою версию Qt тащить? Статика как раз в этом плане намного компактнее будет. Вот использование Qt из реп дистрибутива действительно даёт существенную экономию. Но это под каждый дистрибутив и каждый релиз своя сборка нужна, со всеми вытекающими.

для MacOS - через macdeployqt с их слабой линковкой и так сойдёт.

А подробнее про этот пункт можно? Я macdeployqt пользуюсь, но в чём у макоси слабость линковки — не в курсе, к сожалению.

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

проще наделать скриптов для LXC или даже какой-нибудь менеджер конфигураций использовать, не будет гемора со всякими ентрипоинтами, меньше будет тупить и падать на лишних подсосах всего из сети

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

проще наделать скриптов для LXC

Докер попсовее, для него больше статей, примеров конфигураций. Для новичков проще. Но что использовать - это дело вкуса.

не будет гемора со всякими ентрипоинтами

только не говори что у тебя и с ними проблема)))

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

только не говори что у тебя и с ними проблема)))

когда сам делаешь докерфайлы с его особенностями и ограничениями всегда реально мучаешься. В шелл-скриптах немного парит только синтаксический сахар, тогда как докер - фрактал неочевидного поведения и магических трюков. Единственное значимое преимущество докера это веб-сервисы развертывающиеся как из пакетов, но значимо оно в первую очередь для фанатов макоси и оффтопа, слабо знакомых с пакетными системами.

Syncro ★★★★★
()
Последнее исправление: Syncro (всего исправлений: 1)
Ответ на: комментарий от Syncro

когда сам делаешь докерфайлы с его особенностями и ограничениями всегда реально мучаешься.

Ты не поверишь, для него тоже есть доки. Но я помню что ты их не читаешь)

Единственное значимое преимущество докера это веб-сервисы развертывающиеся как из пакетов, но значимо оно в первую очередь для фанатов макоси и оффтопа

Контейнеризация в целом и докер в частности изначально это линукс и только линукс. Не придумывай.

PRN
()

Так эта…. На смотреть readelf’ом, от каких динамических либ зависят всё зависимости данной проги, и делать это рекурсивно, и просто всё копировать в директорию для последующего chroot.

seiken ★★★★★
()
26 августа 2024 г.

Всем спасибо за ответы!

Попробовал все варианты, в итоге было решено остановиться на сборке в Docker как самом удобном варианте. Код получился немного кривой, но в итоге данное решение работает.

До сих пор не разобрался только со сборкой под ARM для Windows (там прям совсем какие-то нетривиальные инструкции, я пока не пойму как это делать).

С FreeBSD тоже нормально не разобрался, т.к. для сборки там нужно собрать environment с нужными либами и уже его использовать для сборки. Выше в комментариях говорили, что во FreeBSD не должно быть проблем с зависимостями, с которыми я сталкивался, поэтому скорее всего я просто не умею его готовить и мне надо раскурить больше мануалов.

Текущий прогресс залил сюда: https://github.com/danields966/qt_experiments

danields966
() автор топика
Ответ на: комментарий от hobbit

Скорее всего разные версии библиотек в Ubuntu у меня были, потому что я установил на виртуалки немного разные версии дистрибутивов (16.04.7 для amd64 и 16.04.6 для i386)

danields966
() автор топика
Ответ на: комментарий от XMs

Вполне себе жив, текущая Qt поддерживает и cmake, и qmake. Да, cmake в положении «любимой жены», но это, на мой взгляд, потому, что пишут её не они, и им так спокойнее. А технически qmake куда приятнее.

P.S. Но на самом деле и то, и другое набор костылей. Нет нормальной сборочной системы для C++. Более-менее приближение к норме идёт в meson (но его Qt не поддерживает), ещё лучше в плане синтаксиса/читаемости выглядит Bazel (та же беда плюс к нему нужна рота девопсов, чтобы хотя бы понимать его сообщения об ошибках – он, как некоторые пишут, и разрабатывался строго для крупных компаний, для которых это не проблема). Поэтому, повторюсь, для проектов на Qt/C++ наименьшим злом я считаю qmake, хотя там тоже есть к чему придраться.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 3)

Чисто теоретически, под этот сценарий должна идеально подходить Gentoo. Там и кросс-компиляция разная, и докером можно протестировать…

Shushundr ★★★
()