Форум пользователей Slackware Linux

Подскажите, можно ли помимо 5.3.0 установить более старшую версию компилятора и как их переключать в системе не удаляя стоковый gcc? Или нужно пересобирать пакеты? Будут ли какие-то проблемы при таком использовании компилятора7

Всегда можно собрать и установить параллельно.
Однако, для работы собранного им софта млогут потребоваться некоторые приседания в виде дополнительной настройки окружения такого софта.

_________________
irc://freenode.net/##slackware-ru

тут надо немного подтянуть теорию о том "как это всё работает".
Для корректной работы новособраного gcc его нужно поместить в самодостаточное окружение и запускать под специально для этого созданным юзером и в некоторых (особо запущенных)случаях chroot просто будет необходим.
Это достаточно нетривиальная тема.
Могу выложить мануал, но "чукча не писатель, чукча курить однако любит", поэтому могу дать ссылку на саму теорию в первоисточнике, а там уже, если не допрет, могу подсказать что к чему.

Сбрасывайте всё что есть в тему.

тут не совсем понятно что тебе конкретно надо. Если ткнуть пальцем в небо то вот так:
исходная система slackware64-current without multilib
исходный GCC версии 7.2.0
исходный Glibc версии 2.26

какие рифы на пути у "Черной Жемчужины" ? Первый самый явный это обратная совместимость версий GCC и Glibc. Если попробовать перепрыгнуть через версию, например с 7.2.0 на 5.4 то скорее всего ничего не выйдет, так же если попытаться собрать gcc-5.4 c уже установленной в системе Glibc-2.26 то можно словить фейл. Поэтому исходные условия и конечные требования крайне важны для составления стратегии.

Из того что проверено и работает - понижение\повышение версии на один шаг допустимо и создаёт рабочие бинарники. Если нужен шаг в более чем один, то имеет смысл просто последовательно понижать версию.

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

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

Об этом не может быть и речи, если только разговор не про минорное обновление (а оно такое ни к чему в параллельной установке).
Обычный вариант: собираем gcc любым компилятором, затем пересобираем самим собой. И только так.

_________________
irc://freenode.net/##slackware-ru

ну это упрощает задачу.
Продолжу таки следствие - в шапке 5.3.0, т.е. стоковая 14.2. Да, что-то я далеко ушёл от этого, придётся наощупь по памяти(у меня сейчас последняя current с multilib от Алиена да ещё и последние кеды )

в общем опишу последовательность через кросскомпилятор, она даёт самый предсказуемый вариант.
Сперва только теория, без кода и примеров, если что поправляйте где считаете иначе.
Естественно подразумевается что все исходники вот они, в руках.
Первое что нужно это создать профильного юзера, в Слаке есть удобные инструменты типа adduser, для повседневной работы удобно, но для конкретно этой цели негодно, так как нужен полностью чистый профиль не включенный ни в какие группы и без умолчальных настроек skell. Все настройки профиля будут индивидуальными(чуть позже опишу)
Второй шаг создаем места где будем собирать всё это хозяйство, варианты в /tmp для этой задачи не годятся, так как случай особый и всё упирается в корень / , решается симлинками, хотя можно прибить и гвоздями в любое место.
Третий шаг собирает чистый кросскомпилятор с минимальным окружением.
Четвёртый шаг собирает собственно конечный продукт.

что собственно включает в себя последние два пункта?
Чтобы исключить паразитные наводки из основной системы компилятору нужно минимальное окружение Вот список пакетов которые его создают(версии не указываю, они берутся из стокового дерева пакетов вместе с патчами если они есть):

сам gcc в этой стадии собирается дважды. На выходе получится самодостаточное дерево кросскомпилятора практически не связанное с основной системой, с помощью которого уже можно собирать целевой компилятор.
Он так же требует минимальный набор, но уже намного больший по сравнению с предыдущим этапом, вот список:

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

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

Можно и по простому, но результат будет удручающим, наводки из основной системы могут превратить банальную сборку "hello world!" в зубодробительный квест. Тут просто надо понимать как вообще устроен и работает любой линукс. В двух словах очень сложно описать, но попробую:

Связка linux-headers→pkg-config→binutils→gcc→glibc→gcc→glibc(рекурсия gcc→glibc→gcc→glibc не опечатка - это фича) является глобальным фундаментом на основе которого строится вся система без относительно к названию дистрибутива. Это как говориться азы азов. Поэтому при изменении любого из перечисленных компонентов просто необходимо изменять все последующие части системы. В общем это теория, кому-то ещё интересна сама практика ?

Если таки нужно продолжение то озвучивайте, постараюсь разложить.

Вот тут было бы проще отдельный chroot. Но это на мой взгляд.

_________________
irc://freenode.net/##slackware-ru

это оно и будет в конце, корень выбран по одной прагматичной причине - изменение временного спека исходников gcc выглядит следующим образом(это пример, фрагмент реального патча, о котором я говорил выше):


обрати внимание на исходное состояние, всё намертво прибито гвоздями к корню, там примерно 200 таких фрагментов, и самый простой способ это просто воткнуть "/tools/lib" но можно указать и любой другой путь, так у Патрика это дерево спрятано в /usr/x86_64-slackware-linux , как он патчит спеки я не нашёл, но это собственно секрет полишинеля, там всё просто.

ну что, пожалуй начну по тихоньку кропать, что-то инет тупит, видимо провайдер решился таки патчить сервера, поэтому как там получится так получится. Для нетерпеливых и въедливых - все описанные ниже действия я проворачивал на slackware-14.2, slackware64-14.2, slackware-current, slackware64-current и slackware64-current&multilib, последний имеет свои особенности и потому я не буду тут его описывать, кому надо может исследовать это самостоятельно, вдохновение я черпал, помимо официальных ресурсов gcc и исходных текстов в следующих проектах:

http://trac.clfs.org/ - основной проект, на нем построена данная концепция, не смотря некоторую избыточную сложность, в результате она оказалась намного гибче и удобнее.

http://www.linuxfromscratch.org/lfs/ - это как шпаргалка по самым последним обновкам и фичам, которые так или иначе попадают во все без исключения дистры, в том числе и в Слаку(причем одну из первых)

На основе проделанной работы я состряпал собственный проект https://github.com/gramozeka/CBLFS-SemiAutomatic
в приложении к данной ветке обсуждения интересен только раздел https://github.com/gramozeka/CBLFS-Semi ... BaseSystem в части исполнения скриптов 01 и 02.

Итак первый шаг -( жахнув стакан рома и грязно выругавшись как истинный пират) таки решили мы что-то там собрать.

Сперва определим место в системе куда мы всё сложим, чтобы не выдумывать велосипедов пойдем по пути патриарха и создадим в /usr например GCC-Next, тут нет каких-то правил, как говорится каждый суслик агроном..


теперь в главном корне создадим симлинки на будущее дерево:



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


Building - здесь будем собирать
Temporary-System - сюда сложим сборочные скрипты(позже объясню что и как)
cross-tools - сюда сложим сборочные скрипты первой стадии
sources - сорцы и патчи.

Тут маленькая ремарка - я всё это увязал в систему скриптов по принципу тыцнул главный и пошёл дальше по своим пиратским делам, но это всё по большей части и не обязательно, можно просто сидеть и в онлайн-режиме выводить фуги на клавиатуре "как в кине хакиры делают", дело хозяйское. Сразу предупрежу - слаковский набор исходников и слакбилдов нужен, а вот сами слакбилды использовать не получится, только как примеры.

Теперь нужен главный суслик-агроном, то бишь спец-юзер:



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

что понадобится со стороны?
1. патч для спека gcc: http://ftp.clfs.org/pub/clfs/conglomeration/gcc/ здесь всё что нужно, ориентироваться по ближайшей версии, в рамках минорных релизов они подходят друг к другу, при желании можно изменить пути на свои, но тут нужна осторожность и понимание самих действий.
2. Pkg-config-lite-0.28-1 http://sourceforge.net/projects/pkgconf ... 8-1.tar.gz
это адаптированный упрощенный вариант системного pkgconfig, без ненужных для данной операции частей и зависимостей.
выше я уже привел список пакетов , тут, в данном треде, я приведу пример "аки хакир", т.е. сборка живьём.

cross-tools - первая стадия, само действо занимает на хорошем железе минут сорок.

складываем, согласно приведенного списка, все исходники и патчи(например glibc у Патрика имеет несколько таких)
в sources. Вообще лучше сразу всё сложить и для первой и для второй стадии, чтоб больше к этому не возвращаться.

дальше, пока под рутом, меняем владельца и заходим под новых юзером:

переходим в сборочную:

тут момент для понимания - стандартное действие у нас будет состоять из нескольких частей:
0. Зайти в сборочную площадку, как выше я уже упоминал это будет папка Building.
1. Очистить сборочную площадку
2. Распаковать исходник
3. Зайти в папку с распакованными текстами
Эти действия в дальнейшем описании я просто опущу и буду описывать действия после пункта 3.

теперь собственно приготовление самого юзера:



Команда set + h отключает хэш-функцию bash. Хеширование обычно полезно. Bash
использует хеш-таблицу для запоминания полного пути к исполняемым файлам, чтобы
избежать повторного поиска PATH, чтобы найти тот же исполняемый файл. Однако
новые инструменты следует использовать, как только они будут установлены.
Выключив хеш-функцию, оболочка всегда будет искать PATH, когда программа будет
запущена. Таким образом, оболочка найдет вновь скомпилированные инструменты в /
cross-tools, как только они будут доступны, не сохранив предыдущую версию той же
программы в другом месте.
применим настройки учетной записи:

Во время создания инструментов кросс-компиляции вам нужно будет установить
несколько переменных, которые будут зависеть от ваших конкретных потребностей.
Первой переменной будет триплет хост-машины, который будет помещен в переменную
CLFS_HOST. Чтобы учесть, что хост и цель - это одна и та же архитектура, поскольку
кросс-компиляция не будет работать, если хост и цель одинаковы, часть триплета
нужно немного изменить - в нашем случае мы изменим часть триплет к «cross».
Установите CLFS_HOST, используя следующую команду:

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

Нам нужно будет установить целевые флаги для компилятора и компоновщика:


Теперь добавьте все эти переменные хоста и цели, а также флагов компилятора и
компоновщика в ~ / .bashrc, на случай, если вам придется выйти и перезапустить
здание позже:

ну а теперь собственно начинаем собирать первую часть марлезонского балета:

не забываем мы в усечённой учетке пользователя clfs, это важно, оно не даст нам угробить систему !
File-


Linux- Headers
тут берём исходники ядра, распаковываем их и зайдя в них выполняем:

M4-

Ncurses-
в исходном состоянии для 14.2 у Патрика два патча, можно просто применить их как есть в слакбилде(предварительно поместив их куда нужно), немного изменив пути на наши:

Pkg-config-lite-0.28-1

GMP-

MPFR-
в 14.2 mpfr 3.1.4 без патчей, но если вдруг что-то пойдёт не так то вот тут есть нужные исправления http://ftp.clfs.org/pub/clfs/conglomeration/mpfr/

MPC-

ISL-


Binutils-
тяжёлая тема - в новых версиях практически всё исправили, а вот 2.26 "не получился " что-то семнадцать патчей, "это просто праздник какой-то"© , ну тут вариант просто выдрать кусок слакбилда(вместе с патчами разумеется), либо попытаться собрать что-то посвежее, приведу пример с патчами:

стоит обратить внимание, некоторые пакеты крайне чувствительны к чистоте дерева исходников, поэтому директория сборки выносится за пределы дерева.
GCC-
ну вот и собственно то, зачем всё затевалось:
gcc-5.3.0-pure64_specs-1.patch

это был первый проход, после сборки glibc будет второй.

Glibc-
сложный случай, но патчи тоже берутся слаковские:

по сиду вопрос открыт, в новых версиях он не нужен, если что-то пойдет не так то стоит его исключить.
ну и финальный проход с gcc :


на этом кросс-компилятор готов. Теперь самый не простой и ответственный этап - создание независимого дерева минисистемы в который можно делать chroot и безопасно творить всё что взбредёт в голову. Ближе к ночи продолжу если кому интересно, критика приветствуется, возможно где-то напорол, проверяйте.

итак, собрали кросс-тул, но это ещё не компилятор, это только компилятор Компилятора, кагбы и им можно решать определённые узкоспециальные задачи, но для практического использования он малопригоден. следующий этап позволит этот недостаток устранить.
Сразу оговорюсь, в шапке темы вопрос только о gcc, однако следующий этап выходит далеко за рамки первоначального вопроса, сам по себе компилятор крайне ограниченный инструмент, всю силу ему даёт окружение, вот его то по большей части и придётся собирать, я привожу только самый минимум, реально данный тулчейн можно многократно усилить введя в него дополнительные инструменты, например пакетный менеджер slackpkg и массу других вещей, но так же стоит учесть что это всего лишь временный инструмент, поэтому выбор баланса между необходимым и достаточным это всё на ваше усмотрение.

Итак продолжим. Прежде всего добавим новые переменные этого нельзя пропустить, так как от этого зависит успех всего мероприятия, всё под тем же усечённым пользователем:


начало практически повторяет предыдущий этап, но есть и отличия:
GMP-


MPFR-


MPC-


ISL-


Zlib-


Binutils-


GCC-

тут небольшой момент, в старых версиях следующий финт был необходим, но я сейчас уже не помню нужен ли он для 5.4 приведу его на всякий пожарный(он предотвратит поиск GCC в неправильных каталогах для заголовков и библиотек):

делался он именно после configure, на новых версиях (7.2.0) это уже не нужно.
далее устанавливаем:


Ncurses-


Bash-
в слаковском баше море патчей, нужны ли они решайте сами, как их применять можно подсмотреть в слакбилде, тут я приведу компромиссный вариант из одного патча : http://ftp.clfs.org/pub/clfs/conglomera ... te-6.patch


Bzip2-


Check-


Coreutils-
патчи слаковские


Diffutils-
патчи слаковские


File-


Findutils-
патчи слаковские


Gawk-


Gettext-
тут вариантов два - минимально для корректной работы нужно только msgfmt , но практика показала, что лучше собрать его весь, потому как некоторые программы внезапно требуют пощекотать за ушком и мягкие тапочки, поэтому привожу полный вариант:

если по каким либо причинам не срастётся, то вот кастрированный вариант:


Grep-


Gzip-


Make-


Patch-


Sed-


Tar-
Патрик использует две версии тара, одна майнстрим, вторая древняя как моя прабабка, мотивирует он это тем, что в новых версиях тар не пойми как работает через известное место и вызывает много вопросов к его создателям, если вы планируете интегрировать в тулчейн pkgtool то тогда стоит внимательно изучить патриковскую версию сборки тара, я не буду тут это разбирать, приведу простую ванильную форму:



Texinfo-


Util-linux-


Vim-
апстримовский патч, можно не ставить, но для полноты картины : http://ftp.clfs.org/pub/clfs/conglomera ... te-7.patch


XZ Utils- (ака xz-5.2.2.tar.xz )


на этом сборка тулчейна окончена. Если всё собралось правильно и без ошибок, юзер clfs больше не нужен, как и симлинки в корне на tools и cross-tools, а так же наша импровизированная сборочная площадка в /usr/GCC-Next/toolchain/ их можно удалить. В usr/GCC-Next остаются только tools и cross-tools, в первом готовый к использованию компилятор с минимальным окружением, во втором некоторые части нужные для правильной работы первого в рантайме. Вся линковка, которая пойдёт от работы tools уже не будет зависеть от cross-tools.

В usr/GCC-Next можно делать chroot, для этого в ней нужно создать какое-то подобие системного дерева. Делается это из рута так:



при повторном чруте создаваль симлинки и ноды не потребуется, сама последовательность получит вид:



собственно всё. Дальнейшие шаги подразумевают построение новой системы, для законченности приведу вкратце
что нужно сделать(Внимание ! делается это после того как вы УЖЕ вошли в chroot и видите приглашение " [!I have no name! ] \ "), но это уже другая тема:

PS\\ да забыл сказать - на этом этапе в линковщике прописан путь к /tools чтобы избавиться от него стоит собрать базовый системный минимум, но тут уже будет полноценная система, в моём проекте это скрипты 03 и 04, там же есть и команда очищающая линковщик от этого пути.

всё. Кидайтесь какашками.

2admins:
Если всё это работает, имхо, надо в вики это поместить.

2gramozeka:

_________________
с кем поведешься - так тебе и надо!
http://slackware.su

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

Хозяйке на заметку:
у Эрика есть параллельный системному компилятор в виде слакбилда:
http://www.slackware.com/~alien/slackbuilds/gcc5/

_________________
irc://freenode.net/##slackware-ru

объясните мне в чём прикол иметь ещё один компилятор? Не, понятно что есть маргинальные программы на которые давно забили разработчики, а некоторым лень переучиваться на что-то отличное от виндовс98. Но всё же вопрос.

Я выше уже упоминал, ещё раз повторю гсс+глибс+хедеры это основание системы, всё что вне этого по большей части седло для коровы.

Это и ответ. PaleMoon и gcc-java для бутстрапа OpenJDK.

https://alien.slackbook.org/blog/what-i ... headaches/

_________________
irc://freenode.net/##slackware-ru

понятно. Я это называю синдром гнома-поттеринга.

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

А как его использовать не удаляя стоковый gcc? Или это апдейт?