Автор Тема: Инструментальные средства сборки базовой системы  (Прочитано 1387 раз)

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Как же появляются пакеты этой минимальной среды? Очевидно, что без первоначальной bootstrap сборки тут не обойтись.
Так это сделано давно. Или речь, действительно, про новую архитектуру ?

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
И видимо так же происходят обновления элементов toolchain (таких как gcc и glibc), когда начинается переход на их новые версии в самом Alt Linux?
Нет. Просто собирается очередной пакет в репозиторий. То, что необходимо, пересобирается вместе с ними, что нет - пересобирается позднее по иным поводам. Более того, версий именно gcc в репозитории более одной и, при необходимости, в спеке можно указать конкретную. Без указания используется самая новая.

Оффлайн finalizer

  • Начинающий
  • *
  • Сообщений: 13
Нет. Просто собирается очередной пакет в репозиторий. То, что необходимо, пересобирается вместе с ними, что нет - пересобирается позднее по иным поводам. Более того, версий именно gcc в репозитории более одной и, при необходимости, в спеке можно указать конкретную. Без указания используется самая новая.
Разве gcc версии X собранный в системе с glibc версии Y обязательно будет таким же, как gcc той же версии, собранный в системе с glibc версии Z? Аналогичный вопрос и про glibc, собранный разными версиями gcc. Ведь в обоих случаях у каждого из них запускается configure, который тестирует текущую систему, включая системные gcc и glibc, и результаты такого тестирования, а значит и результаты сборки, могут отличаться. Возникает проблема курицы и яйца (видимо из-за которой в bootstrap компилируют по кругу несколько раз) или всё же не возникает?

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Не уверен, что что-то в поведении (в плане генерации кода) у gcc меняется из-за версии glibc, с которой собран gcc. Но, в любом случае, обновление glibc в репозитории происходит без бутстрапов. С gcc может быть чуть сложнее - кажется бывает через самобутстрап. То есть, сначала собирается новый мажорный урезанный gcc посредством gcc имеющегося, а потом уже рабочий полный. Но точнее - это к мантейнеру gcc. Ну или, например, по датам проследить появление в Сизифе gcc6. Но это точно не касалось всего остального репозитория в момент его появления. Вот уже потом, когда пересборка чего-то отвалилась, поломавшиеся пакеты починили (в большинстве; что-то заброшенное могло и остаться).

Оффлайн finalizer

  • Начинающий
  • *
  • Сообщений: 13
Не уверен, что что-то в поведении (в плане генерации кода) у gcc меняется из-за версии glibc, с которой собран gcc.
gcc - это не только компилятор, но так же и свой набор библиотек, например там есть libstdc++-v3. Этот libstdc++-v3 может вызывать функции из glibc (и наверняка делает это), но в разных версиях glibc реализован немного разный набор функций. Наличие функций, которые необходимы программе (в нашем случае libstdc++-v3), проверяются скриптом configure и в случаи их отсутствия могут заменяться на собственные реализации или макросы. Если в glibc версии Z добавили функцию, которой ещё не было в предыдущей версии Y и которая используется в libstdc++-v3, сборка libstdc++-v3 будет несколько иной, несмотря на то, что позже новая версия glibc всё же будет собрана. Более того в случае inline использования функций libstdc++-v3 в прикладной программе будет отличаться и сборка этой прикладной программы.

Но я сейчас посмотрел в репозитории, оказывается gcc в Alt Linux (и не только в нём) разбит на несколько пакетов. В частности libstdc++-v3 - это отдельный rpm. Интересно, эта разбивка стандартна и взята из официальной документации gcc или в каждом дистрибутиве решают по своему как разбивать одит тарбал на модули?

С gcc может быть чуть сложнее - кажется бывает через самобутстрап. То есть, сначала собирается новый мажорный урезанный gcc посредством gcc имеющегося, а потом уже рабочий полный. Но точнее - это к мантейнеру gcc.
Да, я читал об этом. В исходниках gcc есть собственный механизм bootstrap основанный на троекратной сборке gcc самим собой. Но это внутренний bootstrap gcc, который не относится к glibc и к остальным внешним компонентам, которые он использует.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
наверняка делает это), но в разных версиях glibc реализован немного разный набор функций.
Это не важно. Функция либо есть, либо её нет. Может быть изменена реализация, но вход и выход меняться не должен (если это не устранение ошибки). Соответственно, может быть влияние на скорость, на объём используемой памяти и т.п., но не на результат. Ну или если функция необходима, но отсутствует, то что-то просто отвалится.

Оффлайн finalizer

  • Начинающий
  • *
  • Сообщений: 13
Так по какому же принципу gcc разбит на множество пакетов? Эта разбивка на пакеты придумана разработчиками Alt Linux или она одинакова в большинстве дистрибутивов?

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 246
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
Разбиение на пакеты - это пррогатива мантейнера пакета. В Альт принято "крошить мелко", что-бы можно было в сборочную среду ставить минимум пакетов.
По этой причине, я думаю, что разбиение на пакеты может не совпадать в разных  репозиториях.
« Последнее редактирование: 03.12.2017 07:26:50 от ruslandh »

Оффлайн gvy

  • alt linux team
  • ***
  • Сообщений: 1 008
    • Альт на Эльбрусе
    • Email
Попробую кратенько ответить.
0) "просвятить": батюшек в команде и на форуме не припоминаю (а вот в рассылках как-то и архимандрит бывал);
1) bootstrap не входит в функциональность hasher, он оперирует уже имеющимся бинарным репозиторием (в объёме "от rpm-build и его зависимостей") и src.rpm (или эквивалентным pkg.tar, так делает gear);
2) альтовскими скриптами можно пользоваться где угодно, просто это может повлечь за собой необходимость переноса половины альта в целевое окружение (по крайней мере в сборочной части);
3) нет, hasher не собирает toolchain, а берёт для чрута собранные бинарные пакеты;
4) из рассылок имеют отношение devel-ports@ и devel-newbies@;
5) цель занятная, но у нас сейчас с трудом хватает времени вводить новых сотрудников на примерно такие же задачи (например, мне бы не помешал хотя бы ещё один помощник по e2k, а glebfm@ и его ребята загружены MIPS'ами) -- боюсь, любопытство придётся удовлетворять в основном самостоятельно, помочь сможем разве что ключсловами/ссылками;
6) glebfm@ реализовал автобутстрапилку, которая именно что с нуля собирает -- пожалуй, вот эти скрипты и правила были бы Вам наиболее интересны, но документированы они сейчас на языке shell;
7) кросс-компиляция для сборки в альтовые репозитории не применяется, только нативная -- однако скрипты из предыдущего пункта на первых стадиях её делают даже на той же архитектуре;
8) про обновление toolchain и glibc стоит спрашивать glebfm@ почтой, но если в Москве/области обитаете -- лучше договориться с ним да приехать посмотреть в какой-нить такой день, вон gcc7 дожидается своей очереди и glibc 2.26 тоже;
9) разбивка оного в главном перекликается и между дистрибутивами сопоставимой направленности, но детали могут отличаться (например, у нас обязательно отбиваются в сторону gcc-c++/libstdc++, поскольку они необязательно входят в сборочную среду);
10) майнтейнеры обычно и впрямь видят скорее работу по исправлению сломанных новым тулчейном пакетов, а не работу по его обновлению.

2 asy: хотелки бывают разные ;-)
2 sb: не ошибёшься :-)
--
Michael Shigorin | ALT Linux Team | ANNA-News | Сделано у нас | altlinux.org/эльбрус