1 (24.09.2017 00:58:21 отредактировано gramozeka)

Собственно о чём речь - LFS есть на английском, нужно ли сюда(на форум) это переводить(не буквально слово в слово, а как практическое руководство к действию), кому интересно и вообще.
  Сам по себе LFS это только заготовка, если погрузится в этот вопрос достаточно глубоко, то возможно создать полноценную систему, времени это занимает примерно неделю(плюс-минус) если сидеть у компа весь день и ни на что не отвлекаться. Называется это BLFS и как расширенный вариант с кросплатформенной частью CBLFS, последний отличается в корне от изначального LFS как последовательностью сборки так и некоторыми фичами.

PS/ и не стесняйтесь высказывать свои пожелания и вопросы.

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

2

Если хотите поделиться личным опытом, то почему и нет. ab  Вам же самим будет таблетка для памяти. Лично мне интересно, но страшновато. Генты как бы хватает, но приблежается зима и кто его знает...вполне может и быть... be

3

shtoom, Эх гента это очень очень сложно, LFS есче конечно сложнее  ac
gramozeka, Не ну почитать будет интересно пожалуй, я за.

Спросить - стыд минуты, не узнать - стыд всей жизни

4 (28.09.2020 11:05:35 отредактировано gramozeka)

lone_wolf пишет:

shtoom, Эх гента это очень очень сложно, LFS есче конечно сложнее  ac
gramozeka, Не ну почитать будет интересно пожалуй, я за.

Сори за долгое отсутствие, дела навалились - не переделать.
  В общем опрос надо было сделать подольше, чёт не подумал, как и ожидал тема не сильно востребована восемь против двух. Сам объём "чтива" достаточно большой для форума, даже если сильно обрезать.
   В ближайшие дни(не буду зарекаться), постараюсь залить на ГитХаб весь проект, собственно он готов, осталось "самая малость" сочинить wget-list, что-то около 700 пакетов.
Что за проект - как-то мне поднадоело читать о новых выпусках KDE, как там всё красиво и классно, а практически ни в одном дистрибутиве мейтейнеры, по понятным причинам просто не поспевают за мейнстримом, да и эти вечные пляски с пакетными менеджерами, которые с лёгкостью сносят пол-системы из-за одного пакета... В общем погрузился в тему основательно. На выходе получилось нечто монстуозное, которое собирает систему просто с нуля до готового вайна со стимом(под вайн есно, нативный мне не интересен пока).
  За основу я взял два проекта - собственно сам LFS(Linux From Scratch) и его ответвление CLFS(Cross-Linux From Scratch:x86_64-Multilib), с их более развернутыми продолжениями - BLFS(Beyond Linux® From Scratch)  и CBLFS(Cross Beyond Linux® From Scratch), плюс пришлось немного использовать наработки Slackware в частности pkgtool, за его простоту, предсказуемость и безотказность.
  Всё это дело на Bash'е, писано с нуля, не всё конечно гладко, я тот ещё кодер-индус, со временем конечно причешу и уберу лишнее, но это пока в планах.

Вот собственно так как-то... bk
*** Добавлено: 29.10.2017 19:20:56 ***

Вот ссылка на сборочный конвейер, все описания в ReadMe-Now, возможно какие-то ошибки всплывут, вношу правки иногда, может кому-то и пригодится.  bn
https://github.com/gramozeka/CBLFS-SemiAutomatic

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

5 (28.09.2020 11:05:59 отредактировано gramozeka)

githab стал некошерен, перехал на gitlab.
Вот ссылки на проект :
старый(поумирали некоторые ссылки в загрузчике, но при желании их можно найти в архивах и докачать вручную) : https://gitlab.com/Gramozeka/Genesis-cblfs
а это новый(актуален на 25.04.2019) : https://gitlab.com/Gramozeka/cross-blfs .
Загрузчика нет, пока. Но есть примерный список - по названию тарбола все ищется в гугле за секунду. все списки в соответствующих директориях. Проект сырой, но уже рабочий, пишу с него. Если у кого есть проблемы с кросс-компиляцией, в разделе https://gitlab.com/Gramozeka/cross-blfs … ASE_SYSTEM есть два тарбола, это готовый тулкит для сборки. Распаковать в чистый раздел будущей системы и можно начинать собирать в chroot со стадии №2(в инструкции), не забудьте только исходники загрузить.


perl и python модули я гружу вручную через cpan и pip/pip3 , можно конечно заморочиться и опакетить, но слишком это трешово, для texLive перлу нужно больше 30 модулей с зависимостями, если это всё начать опакечивать можно двинутся, поэтому пока так. Wayland работает, но так и не осилил настроить weston, работает всё через... как у Потеринга в общем, да и невидия до сих пор не дружит по уму с ним.  Тайминг сборки около 50 часов, но если подкрутить оптимизацию и настроить ccache то можно ускорить, я этим не занимался.
Пишите, форкайте, критикуйте, после второго инфаркта мне недолго осталось, так что может кому сгодится мозги потренировать.

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

6

gramozeka пишет:

после второго инфаркта мне недолго осталось

bw Это куда ты там намылился? А мастер-классы "на все руки мастер" кто проводить будет? ai

Linux Mint 19.3 Mate Edition
Windows 7

7

Wolfenberg, Вот-вот,совсем человек совесть потерял... ab

8

Wolfenberg пишет:

А мастер-классы "на все руки мастер" кто проводить будет?

сами, всё сами, ищ обленились, "..во-о-от мы в ваше время !"... ag
как говорят на лоре "нинужна". Достаточно документации в /usr/share/doc{,info}(/usr/doc{,info}).
Никогда раньше внимания не обращал, а тут залез случайно и залип на месяц - это ж  клондайк знаний, даже интернет не нужен, сиди читай, вся система под микроскопом.

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

9

gramozeka, Ну, нет. Будет еще инфаркт-микарда и вот такой рубец. bv  ab

10

gramozeka пишет:

сами, всё сами, ищ обленились, "..во-о-от мы в ваше время !"... ag

ae  Ни фига! Сам обещал показать болгарку под управлением Gentoo Linux.

Linux Mint 19.3 Mate Edition
Windows 7

11 (06.05.2019 22:44:16 отредактировано lone_wolf)

gramozeka пишет:

после второго инфаркта мне недолго осталось

Отставить паническое настроение, надо верить в лучшее. И да 100 лет желаю вам ещё прожить.  az

Спросить - стыд минуты, не узнать - стыд всей жизни

12

Wolfenberg пишет:

под управлением Gentoo Linux.

хАчуу! ХАчууу болгарку! ((с) Адская белочка)

- Пап, а вирусы под линукс есть?
- Есть, но всего 5, и их сначала нужно откомпилировать под свою систему, дать права на запуск и запустить.
Как сделать и разместить скриншот || Прежде чем создавать тему

13

Wolfenberg пишет:

болгарку под управлением Gentoo Linux.

ai я тоже хочу такое увидеть, это же шедевр

Спросить - стыд минуты, не узнать - стыд всей жизни

14 (06.05.2019 23:18:04 отредактировано gramozeka)

Wolfenberg пишет:

Сам обещал показать болгарку под управлением Gentoo Linux.

пруфы!!
я такого не говорил, но на сие поделие бы глянул...
и таки да! Прекращайте оффтоп, давайте по существу темы.
Тут копался в wine, так обнаружил одну забавную фичу - а именно, оказывается можно построить практически аналог WoW64, для этого нужен корректный multilib и ванильный i686-based, в первом строится чистый wine-win64, во втором чистый wine-i686, потом в первом собирается гибрид wine-win64+wine-i686=wine-multilib.
В таком гибриде корректно работают проги как 32-бит, так и 64-бит, собственно как в любой 64-бит винде.
вот так выглядит дерево такого вайна:
http://www.picshare.ru/uploads/190506/Nizeq2E9yn_thumb.jpg
при winecfg ошибок меньше в разы!(и да, я собираю актуальный staging с ./patches/patchinstall.sh DESTDIR=../$PRGNAM-$VERSION --all
...............

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

15 (21.10.2020 13:41:57 отредактировано gramozeka)

*************** ВВЕДЕНИЕ *****************

Итак дорогие мои, начнём забивание мозгов тем что "НИНУ́ЖНА".

С чего начать? Первое что приходит на ум, это как устроена система с точки зрения самой системы. Но это тупиковый путь, т.к. тема безгранична и до сути вопроса в практической плоскости данного топика можно никогда не добраться, поэтому задекларируем что мы это знаем.  bu
Для построения системы потребуется немного чистого диска, для знакомства хватит пяти гигов(на самом деле всего 600-800 метров, но накладные расходы на сборку и исходники...).
Потребуется система, способная собрать gcc и glibc, что на самом деле довольно не тривиальная задача.
Потребуется специально огороженный юзер.
  Вот с него и начнём.
Делается он так:

 Консоль:

groupadd clfs
useradd -s /bin/bash -g clfs -d /home/clfs clfs
mkdir -pv /home/clfs
chown -v clfs:clfs /home/clfs

passwd clfs


вроде всё как всегда, что особенного?
Если вот прямо сейчас зайти в учётку этого юзера, то он получит все стандартные атрибуты обычного пользователя, на которые, в повседневности никто не смотрит, а тупо пользуется.
Это набор стандартных системных переменных, вот в них-то и вся соль.
Система сама их назначает из глобальных установок в /etc/profile, /etc/skell и остальных конфигураций в /etc, коих там вагон и не один.
  Так вот для собирания(из исходников) кросскомпилятора gcc это всё высокотоксичный актив и от него нужно держаться подальше.
   Для этого есть инструмент в самой системе - это индивидуальный профиль bash. Хранится он в `$HOME/.bash_profile  и `$HOME/.bashrc. Первый инициатор этих установок, а второй - собственно установки.
Работает это так - при логине в профиль, система опрашивает домашний каталог на предмет наличия этих файлов и если они присутствуют, то глобальные настройки из /etc игнорируются.
Для нашей задачи это выглядит так:
cat $HOME/.bash_profile

exec env -i HOME=${HOME} TERM=${TERM} PS1='\u:\w\$ ' /bin/bash

cat ~/.bashrc

set +h
umask 022
CLFS=/mnt/clfs
LC_ALL=POSIX
PATH=/cross-tools/bin:/bin:/usr/bin
export CLFS LC_ALL PATH
unset CFLAGS CXXFLAGS PKG_CONFIG_PATH

вот теперь надо пояснить что есть что.

exec env -i HOME=${HOME} TERM=${TERM} PS1='\u:\w\$ ' /bin/bash
эта строчка указывает системе использовать переменные окружения только из домашнего каталога, никакие другие переменные, кроме объявленных локально не будут учитываться.

set +h

в баше есть функция кеша $PATH, укоряющая поиск приложений, т.е. однажды найденная программа ls по пути /usr/bin/ls, все последующие разы будет находиться по нему, не пересматривая весь $PATH, что разумно для простоты работы. Так вот set +h эту функцию отключает, теперь каждый раз, когда пользователь вводит какую либо команду, она будет находится обходом всего пути указанного в $PATH, зачем это надо я чуть позже растолкую.

CLFS=/mnt/clfs
просто переменная, указывающая где у нас "чистый лист".

LC_ALL=POSIX
тоже понятно? Для тугих - отмена всех языковых установок - только посикс, лютый хардкор девственной консоли.

PATH=/cross-tools/bin:/bin:/usr/bin
собственно PATH, тут важна последовательность поиска, первый же путь оказавшийся валидным и будет применён, если имеется /usr/bin/ls и /cross-tools/bin/ls, то использован будет последний, т.к. он первый в поиске. Это важно для правильного линкования, т.к. задача собрать кроскомпилятор не связанный с базовой системой ничем.

export CLFS LC_ALL PATH
собственно инициация переменных указанных выше.

unset CFLAGS CXXFLAGS PKG_CONFIG_PATH
отмена флагов компилятора если вдруг таковые были где-то заявлены системой.

Собственно с этим всё. Войдя в эту учётку стоит применить :

 Консоль:

source ~/.bash_profile

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

..продолжение следует.
*** Добавлено: 29.09.2020 14:37:17 ***

..продолжим.
Сам по себе компилятор работать не может, ему нужен определённый обвяз. Фундаментом является связка с\с++, уже на ней строится всё остальное - фортраны, бейсики и прочий зоопарк из рептилий и всяких растов.
Подробно останавливаться на том кто есть кто я тут не буду, просто перечислю что нужно:

file
linux(заголовочные файлы ядра)
m4
ncurses
pkg-config
gmp
mpfr
mpc
isl(опционально, пакет не обязательный, но иногда дюже полезный, подробности можно почитать на сайте самого проекта http://isl.gforge.inria.fr/ )
binutils
gcc(собственно виновник этого треша)
glibc

но!!!
это только обвязка! Сам кросс-компилятор собирается отдельно с опорой вот на этот список.

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

...

*** Добавлено: 29.09.2020 15:32:12 ***

... про исходники.
Систем сборки существует море, и каждый день кто-то изобретает что-то новое. Но.. есть исторически сложившаяся практика применения самых древних, первых систем, и, негласное соглашение программистов, работающих над основами системы, использовать только их, вернее Её. Система на основе configure→make→make install.
Вот с её помощью и собирается базовый набор компиляции.
Там не сложно :
В дереве исходников запускается скрипт configure, который обрабатывает по своему алгоритму всё доступное пространство переменных(вот тут то и нужен наш огород!) и составляет последовательность компиляции.
Далее, если конфигурация завершается положительно, make, на основе выхлопа configure собирает всё в бинарные файлы.
А напоследок make же, на основе  выхлопа configure выполняет процедуру install, устанавливая собранное в заранее обговоренные места.

configure, в зависимости от прямоты рук тех, кто его составлял принимает кучу аргументов, расписывающих какие переменные использовать, как и куда устанавливать программы, библиотеки и прочее.
вот тут то и встречается главная засада всех новичков - "как это работает вообще?!!!"... что тут можно посоветовать? - читайте доки(авось поможет). Важно понимать - без знания как этим пользоваться самостоятельно что-то собрать не получится... хотя... дуракам порой везёт, как знать, как знать...
*** Добавлено: 29.09.2020 16:28:29 ***

ну ладно, это всё лирика.
Практика - критерий истины, это нужно знать.
Попробуем создать первый кросс-тул.(их два).
Дальше можно просто копипастить шаги в консоль, позже я прокомментирую что зачем, пока тупо Ctrl+C & Ctrl+V...
Открываем консоль и становимся root'ом натурально:
0.

 Консоль:

su -

Сейчас все действия выполняются от root'а, пока я явно не укажу другое(п. 5)
1.

 Консоль:

export CLFS=/mnt/clfs
mkdir -pv ${CLFS}
mount -v /dev/sdb2 ${CLFS}
install -dv ${CLFS}/tools
ln -sv ${CLFS}/tools /
install -dv ${CLFS}/cross-tools
ln -sv ${CLFS}/cross-tools /

!!! ахтунг !!! /dev/sdb2 - это пример! ставьте своё!

2.

 Консоль:

groupadd clfs
useradd -s /bin/bash -g clfs -d /home/clfs clfs
mkdir -pv /home/clfs
chown -v clfs:clfs /home/clfs

passwd clfs

3.

 Консоль:

chown -vR clfs:clfs ${CLFS}/tools
chown -vR clfs:clfs ${CLFS}/cross-tools
chown -v clfs:clfs /tools
chown -v clfs:clfs /cross-tools
cd ${CLFS}
mkdir sources

!!! ахтунг !!!
Теперь нужно запастись исходниками. Можно просто шарить по сети и тупо качать, можно на сайте проекта прочитать пункт http://www.linuxfromscratch.org/lfs/vie … ction.html
но есть одно "НО", я описываю создание немного более расширенной версии LFS, а именно multilib, там более жёсткие требования к среде, поэтому не всё что описано в LFS будет работать.
вот полный набор ссылок для кросс-компилятора:
1. ftp://ftp.astron.com/pub/file/file-5.39.tar.gz
2. https://www.kernel.org/pub/linux/kernel … 8.9.tar.xz
3. http://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.xz
4. http://ftp.gnu.org/gnu/ncurses/ncurses-6.2.tar.gz
5. http://sourceforge.net/projects/pkgconf … 8-1.tar.gz
6. http://ftp.gnu.org/gnu/gmp/gmp-6.2.0.tar.xz
7. http://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0.tar.xz
8. https://ftp.gnu.org/gnu/mpc/mpc-1.2.0.tar.gz
9. http://isl.gforge.inria.fr/isl-0.22.1.tar.xz(лучше использовать из git !!! → https://repo.or.cz/w/isl.git )
10. http://ftp.gnu.org/gnu/binutils/binutils-2.35.tar.xz
11. http://ftp.gnu.org/gnu/gcc/gcc-10.2.0/gcc-10.2.0.tar.xz
12. http://ftp.gnu.org/gnu/glibc/glibc-2.32.tar.xz

Всё это нужно поместить в только что созданный каталог ${CLFS}/sources и присвоить нашему огороженному юзеру, а потом и войти в учётную запись:

4.

 Консоль:

chown -vR clfs:clfs ${CLFS}/sources
su - clfs

5.(!!! ахтунг !!! теперь очень важные танцы с бубной !!!) мы теперь пользователь clfs и все действия в дальнейшем выполняются от его имени, пока я явно не укажу другое!!!

 Консоль:

cat > ~/.bash_profile << "EOF"
exec env -i HOME=${HOME} TERM=${TERM} PS1='\u:\w\$ ' /bin/bash
EOF
cat > ~/.bashrc << "EOF"
set +h
umask 022
CLFS=/mnt/clfs
LC_ALL=POSIX
PATH=/cross-tools/bin:/bin:/usr/bin
export CLFS LC_ALL PATH
unset CFLAGS CXXFLAGS PKG_CONFIG_PATH
EOF

source ~/.bash_profile

6.

 Консоль:

export CLFS_HOST=$(echo ${MACHTYPE} | sed -e 's/-[^-]*/-cross/')
export CLFS_TARGET="x86_64-unknown-linux-gnu"
export CLFS_TARGET32="i686-pc-linux-gnu"
export BUILD32="-m32"
export BUILD64="-m64"

cat >> ~/.bashrc << EOF
export CLFS_HOST="${CLFS_HOST}"
export CLFS_TARGET="${CLFS_TARGET}"
export CLFS_TARGET32="${CLFS_TARGET32}"
export BUILD32="${BUILD32}"
export BUILD64="${BUILD64}"
EOF

cd ${CLFS}/sources

Ну вот теперь можно собирать...

продолжение следует...

*** Добавлено: 29.09.2020 19:28:58 ***

gramozeka пишет:

Ну вот теперь можно собирать...

...ну да, ну да, собирать. Надо прояснить некоторые моменты до того как.
Есть два подхода к процессу сборки - первый самый тупой и надёжный: зайти в дерево исходника и скомандовать "ату яво! фас!", как там в фильме: "...машина надёжная, убойная, 75 патронов, но весит...", это срабатывает для маленьких наколеночных вещей ака "Hello World!", но для чего-то серьёзного это не годится(если конечно важен не просто результат, а предсказуемый и, что важнее, обратимый результат, когда всё можно обернуть взад).
Для второго нужны скрипты, как правило на баше(не обязательно). В них прописывается весь сценарий сборки целиком, задача просто запустить скрипт и он всё что нужно выполнит.
В первой иттерации пакетирование(ещё одна фишка) не нужно, всё будем делать "по живому", но таки скриптиками запастись стоит...

*** Добавлено: 29.09.2020 20:20:19 ***

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

./configure --prefix=/cross-tools
make -j4
make install

тут важен --prefix=/cross-tools (выше мы сделали симлинк в главном дереве системы на реальное расположение директории). Это нужно для того, чтоб готовые программы, оказавшись в изоляции, продолжали считать своё местоположение от корня.
Но это не всё, для каждого архива набор специфических установок разный. Чуть позже я залью обновлённое дерево на гитлаб, а пока просто приведу по порядку сборки для каждого архива:

file-5.39

./configure --prefix=/cross-tools
make
make install

linux-5.8.9

make mrproper
make INSTALL_HDR_PATH=dest headers_install
mkdir -pv /tools/include || true
cp -rv dest/include/* /tools/include

m4-1.4.18

sed -i 's/IO_ftrylockfile/IO_EOF_SEEN/' lib/*.c
echo "#define _IO_IN_BACKUP 0x100" >> lib/stdio-impl.h
./configure --prefix=/cross-tools
make
make install

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

ncurses-6.2

sed -i s/mawk// configure
./configure \
            --prefix=/cross-tools \
            --with-shared   \
            --without-debug \
            --without-ada   \
            --enable-widec  \
            --enable-overwrite \
            --without-gpm
make -C include
make -C progs tic
install -v -m755 progs/tic /cross-tools/bin

pkg-config-lite-0.28-1

./configure \
    --prefix=/cross-tools \
    --build=${CLFS_TARGET} \
    --with-pc-path=/tools/lib64/pkgconfig:/tools/share/pkgconfig
make
make install

gmp-6.2.0

./configure   \
    --prefix=/cross-tools \
    --enable-cxx \
    --disable-static
make
make install

mpfr-4.1.0

LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
./configure \
    --prefix=/cross-tools \
    --disable-static \
    --with-gmp=/cross-tools
make
make install

mpc-1.2.0

LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
./configure \
    --prefix=/cross-tools \
    --disable-static \
    --with-gmp=/cross-tools \
    --with-mpfr=/cross-tools
make
make install

isl-0.22.1

LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
./configure \
    --prefix=/cross-tools \
    --disable-static \
    --with-gmp-prefix=/cross-tools
make
make install

binutils-2.35

mkdir -v build
cd       build

AR=ar AS=as \
../configure \
    --prefix=/cross-tools \
    --host=${CLFS_HOST} \
    --target=${CLFS_TARGET} \
    --with-sysroot=${CLFS} \
    --with-lib-path=/tools/lib:/tools/lib64 \
    --disable-nls \
    --disable-static \
    --enable-64-bit-bfd \
    --enable-gold=yes \
    --enable-plugins \
    --enable-threads \
    --disable-werror
make
make install

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

gcc-10.2.0 - первый ход, предварительный. Далее директория для сборки будет создаваться вообще вне дерева исходников, для удобства.

patch -Np1 -i ../gcc-10.2.0-specs-1.diff
echo -en '\n#undef STANDARD_STARTFILE_PREFIX_1\n#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"\n' >> gcc/config/linux.h
echo -en '\n#undef STANDARD_STARTFILE_PREFIX_2\n#define STANDARD_STARTFILE_PREFIX_2 ""\n' >> gcc/config/linux.h
touch /tools/include/limits.h
mkdir -v ../gcc-build
cd ../gcc-build
AR=ar \
LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
../gcc-10.2.0/configure \
    --prefix=/cross-tools \
    --build=${CLFS_HOST} \
    --host=${CLFS_HOST} \
    --target=${CLFS_TARGET} \
    --with-sysroot=${CLFS} \
    --with-local-prefix=/tools \
    --with-native-system-header-dir=/tools/include \
    --disable-shared \
    --with-mpfr=/cross-tools \
    --with-gmp=/cross-tools \
    --with-mpc=/cross-tools \
    --with-isl=/cross-tools \
    --without-headers \
    --with-newlib \
    --disable-decimal-float \
    --disable-libgomp \
    --disable-libssp \
    --disable-libatomic \
    --disable-libitm \
    --disable-libsanitizer \
    --disable-libquadmath \
    --disable-libvtv \
    --disable-threads \
    --with-isl=/cross-tools \
    --enable-languages=c,c++ \
    --with-glibc-version=2.11
make -j4 all-gcc all-target-libgcc
make install-gcc install-target-libgcc

сам патч вот тут - https://gitlab.com/Gramozeka/kokoro/-/b … ecs-1.diff , он исправляет пути для автоматического линковщика, чтоб получившийся прекомпилятор не ломился в родительскую систему за каждой мелочёвкой, это важная примочка, но есть современные средства позволяющие получать тот же результат, но тогда надо полностью следовать путём предлагаемым в официальном руководстве и забыть о multilib.

glibc-2.32 32-бита.

mkdir -v ../build
cd      ../build
echo "libc_cv_slibdir=/tools/lib" >> config.cache
BUILD_CC="gcc" \
CC="${CLFS_TARGET}-gcc ${BUILD32}"  \
BUILD_CXX="g++"  \
CXX="${CLFS_TARGET}-g++ ${BUILD32}" \
AR="${CLFS_TARGET}-ar" \
RANLIB="${CLFS_TARGET}-ranlib" \
../glibc-2.32/configure \
    --prefix=/tools \
    --host=${CLFS_TARGET32} \
    --build=${CLFS_HOST} \
    --enable-kernel=3.2 \
    --with-binutils=/cross-tools/bin \
    --with-headers=/tools/include \
         --enable-add-ons \
  --enable-obsolete-nsl \
  --enable-obsolete-rpc \
  --enable-profile \
  --enable-static-nss \
  --disable-werror
    make -j4
    make install

glibc-2.32 64-бита.

mkdir -v ../build
cd      ../build

echo "libc_cv_slibdir=/tools/lib64" >> config.cache

BUILD_CC="gcc ${BUILD64}" \
CC="${CLFS_TARGET}-gcc ${BUILD64}"  \
BUILD_CXX="g++ ${BUILD64}"  \
CXX="${CLFS_TARGET}-g++ ${BUILD64}" \
AR="${CLFS_TARGET}-ar" \
RANLIB="${CLFS_TARGET}-ranlib" \
../glibc-2.32/configure \
    --prefix=/tools \
    --host=${CLFS_TARGET} \
    --build=${CLFS_HOST} \
        --libdir=/tools/lib64 \
    --enable-kernel=3.2 \
    --with-binutils=/cross-tools/bin \
    --with-headers=/tools/include \
       --enable-add-ons \
  --enable-obsolete-nsl \
  --enable-obsolete-rpc \
  --enable-profile \
  --enable-static-nss \
 --cache-file=config.cache --disable-werror
    make -j4
    make install

Тут надо пояснить - материнская система должна уметь в мультилиб! Это без вариантов.

gcc-10.2.0_cross
Собственно первый ход кросс-компиляции, всё что выше это только прелюдия была.

patch -Np1 -i ../gcc-10.2.0-specs-1.diff
echo -en '\n#undef STANDARD_STARTFILE_PREFIX_1\n#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"\n' >> gcc/config/linux.h
echo -en '\n#undef STANDARD_STARTFILE_PREFIX_2\n#define STANDARD_STARTFILE_PREFIX_2 ""\n' >> gcc/config/linux.h
mkdir -v ../gcc-build
cd ../gcc-build
AR=ar \
LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
../gcc-10.2.0/configure \
    --prefix=/cross-tools \
    --build=${CLFS_HOST} \
    --target=${CLFS_TARGET} \
    --host=${CLFS_HOST} \
    --with-sysroot=${CLFS} \
    --with-local-prefix=/tools \
    --with-native-system-header-dir=/tools/include \
    --disable-static \
    --enable-languages=c,c++ \
    --with-mpc=/cross-tools \
    --with-mpfr=/cross-tools \
    --with-gmp=/cross-tools \
    --with-isl=/cross-tools
make -j4 AS_FOR_TARGET="${CLFS_TARGET}-as" \
    LD_FOR_TARGET="${CLFS_TARGET}-ld"
make install

Выполнив всё это, мы получим первый кросс-компилятор, способный собрать полноценное дерево cross-tools, с помощью которого можно собрать готовую систему, причём платформу можно выбирать в широких пределах, на то он и "кросс"... ну а можно и просто хелоуворды кАнпилять, какая разница в общем-то...
PS// об одной "мелочи" я не рассказал, это такая фича как

make check

это девелоперская примочка, позволяющая тестировать собранное на предмет багов и вообще годности к использованию. Она важна с академической точки зрения, но простому обывателю мало пригодна и понятна, однако знать о ней нужно и даже иногда пользоваться. Только стоит учесть - если на сборку(make) глибса уйдёт примерно минут десять, то на make check после неё уйдёт более часа.

продолжение обязательно будет...
*** Добавлено: 30.09.2020 02:19:08 ***

...продолжим.

Маленькое лирическое отступление.
Современные тенденции в мире Linux меня лично не очень радуют. Корпорации медленно но верно прибирают к рукам все наработки сообщества. Потерингиада уже показывает своё истинное нутро, лишая по большей части манёвра и превращая систему в аналог Венды. Это удручает, но многим нравится, с этим тоже нужно считаться. Я несколько раз пробовал это поделие(systemD), но каждый раз убеждался - не стоит тратить на него время, оно как раковая опухоль, суёт свои метастазы в каждый уголок системы, а по последним сведениям и уже в ядро! Мутная, глюкавая, абсолютно не прозрачная прога пытается стать самой системой - это не юникс-вей! Кто бы что не говорил, нравится? Пользуйтесь, дело хозяйское, мы пока ещё в относительно свободном мире. Но по этой дороге я не ходок...

Итак, кросс-тул нейтрален, на его базе можно и системДЭ собрать, главное понимать что творишь, а там дело техники, но не спрашивайте меня как это делать, на сайте проекта есть ветка посвящённая этому чуду-юду.
А я по старинке, на SysVinit.

*******************************************
Важный момент. Мультилиб специфическая штука и во многих дистрах уже свернули работы по его поддержке, поэтому собрать gcc с его поддержкой будет проблематично. Я не совсем дока по части железа, поэтому стопроцентной гарантии не дам, но полный набор инструментов я построил на Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz , обладатели аналогичных железок могут ими воспользоваться.
Лежит тут - https://gitlab.com/Gramozeka/kokoro/-/t … ross-tools
Достаточно распаковать оба архива в нужное место и после небольших манипуляций можно делать chroot в полностью готовую для сборки системы среду. Она уже умеет в мультилиб, поэтому иметь какую-то продвинутую систему не обязательно, лишь бы она(система) умела в chroot, и могла в 64-битное ядро, более-менее свежее.
********************************************

продолжу описание процесса.

...после сборки gcc-10.2.0_cross, мы всё ещё сильно зависим от материнской системы, нам нужны всякие тары, сиды, перлы и прочие питоны с башами. Второй этап это создание этих всех инструментов с привязанным к ним компилятором, который будет зависим только от самого себя.
Вот нужные инструменты по порядку сборки:

gmp
mpfr
mpc
isl
zlib
binutils
gcc
ncurses
bash
bzip2
check
coreutils
diffutils
file
findutils-
gawk
grep
gzip
m4
make
patch
sed
tar
xz
СТОП!!!!!! ЭТО ОТДЕЛЬНАЯ ПЕСТНЯ́!
gettext
bison
perl
Python
multiarch_wrapper
texinfo
util-linux
vim

Некоторые повторяются? ..хм, да, есть такое. Сейчас объясню механизм.
Наша цель с помощью работающей системы с компилятором А, построить работающую систему с компилятором С.
Но, прямым ходом, этого сделать нельзя, ибо динамическая линковка наше всё. Но её можно обмануть.
Схематично это работает так:
А собирает В1(выше это оно) с привязкой к посторонней директории в корне(это важно), со своим набором библиотек и заголовков, никак не слинкованными с основной системой.
Далее В1, собирает для себя вспомогательные инструменты и В2, которые привязаны только к нему, слинкованы с ним, и не имеют с материнской системой ничего общего.
Единственный недостаток - это всё привязано не к корню системы "/ ", а к директории в корне, при том, что имеет некоторые связи с В1.
Так вот когда мы соберём С с помощью В2 основываясь на реальном корне системы "/", мы избавимся и от В1, и от В2, и получим самодостаточный компилятор в нативной среде. Для этого нам понадобится chroot.(но это чуть позже)

В этот раз, мы уже имеем компилятор который к материнской системе не принадлежит, всё ещё оставаясь огороженным пользователем clfs, добавим несколько переменных и изменим саму среду сборки:

 Консоль:

export CC="${CLFS_TARGET}-gcc ${BUILD64}"
export CXX="${CLFS_TARGET}-g++ ${BUILD64}"
export AR="${CLFS_TARGET}-ar"
export AS="${CLFS_TARGET}-as"
export RANLIB="${CLFS_TARGET}-ranlib"
export LD="${CLFS_TARGET}-ld"
export STRIP="${CLFS_TARGET}-strip"

echo export CC=\""${CC}\"" >> ~/.bashrc
echo export CXX=\""${CXX}\"" >> ~/.bashrc
echo export AR=\""${AR}\"" >> ~/.bashrc
echo export AS=\""${AS}\"" >> ~/.bashrc
echo export RANLIB=\""${RANLIB}\"" >> ~/.bashrc
echo export LD=\""${LD}\"" >> ~/.bashrc
echo export STRIP=\""${STRIP}\"" >> ~/.bashrc

Это очень важный момент, так как в окружении пользователя глобально объявлены переменные  CC, CXX и т.д., то при умолчании, скрипты configure, сперва будут искать в системе именно эти компиляторы и инструменты, а в некоторых, так и вовсе только эти переменные и отвечают за правильное обращение к сборочному процессу, а т.к. хеширование у оболочки отключено, то в первую очередь будет найден наш новый кросс-компилятор

x86_64-unknown-linux-gnu-gcc , а не системный gcc.

После объявления этих переменных, можно начинать собирать вторую часть кросс-компилятора(выше список). Подробно расписывать все 33 позиции наверно не стоит, слишком уж много места это занимает.
Подробно можно посмотреть вот тут - https://gitlab.com/Gramozeka/kokoro/-/t … ary-System
там всё должно быть понятно, если есть желание, то немного доработав(заменив или убрав переменные скрипта) можно просто собирать вручную.

На счет "СТОП!!!!!! ЭТО ОТДЕЛЬНАЯ ПЕСТНЯ́!". Это один из тонких моментов.
Некоторые вещи, такие как perl или python, при сборке крайне неразборчивы и мало-управляемые, поэтому практически не пригодны для кросс-компиляции, т.к. собираясь, они находят в системе самих же себя установленных, и наглухо линкуются с тем, что есть, запретить это или как-то ограничить просто не реально. Поэтому, дойдя до этого места, дособирать кросс-тул придётся уже в chroot-окружении.
***************************************
Вернёмся к вопросу возможности материнской системы к собиранию мультилиба, выше ссылка на два архива, если нет возможности собрать нативный мультилиб, то можно воспользоваться уже готовым кросс-тулом, в нем уже собраны все нужные вещи, в том числе и эта пестня с питонами и перлами...
  Кто-то заметил - а что за приблуда multiarch_wrapper ? В самом низу поясню зачем это.
*************************************************

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

Для этого, собрав всё до xz включительно, нужно выйти из учетки clfs, он больше не нужен и его можно удалить из системы полностью, необходимо, оставаясь root'ом, создать в устанавливаемой системе необходимое дерево процессов ака proc, dev, var и т.д., создать ноды(что это вообще за чертовщина!?) и прочие моменты, монтируем это всё хозяйство в ядро работающей системы и выполняем chroot:
(!!!Ахтунг!!! Теперь мы root! Практически партизан в тылу врага, поэтому делаем всё очень вдумчиво и аккуратно.)

 Консоль:

  mkdir -pv ${CLFS}/{dev,proc,run,sys}
  mknod -m 600 ${CLFS}/dev/console c 5 1
  mknod -m 666 ${CLFS}/dev/null c 1 3
  mount -v -o bind /dev ${CLFS}/dev
  mount -vt devpts -o gid=5,mode=620 devpts ${CLFS}/dev/pts
  mount -vt proc proc ${CLFS}/proc
  mount -vt tmpfs tmpfs ${CLFS}/run
  mount -vt sysfs sysfs ${CLFS}/sys
  [ -h ${CLFS}/dev/shm ] && mkdir -pv ${CLFS}/$(readlink ${CLFS}/dev/shm)


а теперь Горбатый!!!(чрутимся в наш шалашик):

 Консоль:

chroot "${CLFS}" /tools/bin/env -i \
    HOME=/root TERM="${TERM}" PS1='\u:\w\$ ' \
    PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
    /tools/bin/bash --login +h

Выполнив это мы увидим вот такую картинку:

 Консоль:

I have no name!:/#

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

Теперь нужно построить всё системное дерево "как у людей":

 Консоль:

chown -Rv 0:0 /tools
chown -Rv 0:0 /cross-tools
mkdir -pv /{bin,boot,dev,{etc/,}opt,lib{,64},mnt}
mkdir -pv /{proc,media/{floppy,cdrom},run/{,shm},sbin,srv,sys}
mkdir -pv /var/{lock,log,mail,spool}
mkdir -pv /var/{opt,cache,lib/{misc,locate},local}
ln -sv lib /var/lib64
install -dv /root -m 0750
install -dv {/var,}/tmp -m 1777
ln -sv ../run /var/run
mkdir -pv /usr/{,local/}{bin,include,lib{,64},sbin,src}
mkdir -pv /usr/{,local/}share/{doc,info,locale,man}
mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -pv /usr/{,local/}share/man/man{1..8}
install -dv /usr/lib/locale
ln -sv ../lib/locale /usr/lib64
ln -sv /tools/bin/{bash,cat,echo,grep,pwd,stty} /bin
ln -sv /tools/bin/file /usr/bin
ln -sv /tools/lib/libgcc_s.so{,.1} /usr/lib
ln -sv /tools/lib64/libgcc_s.so{,.1} /usr/lib64
ln -sv /tools/lib/libstd* /usr/lib
ln -sv /tools/lib64/libstd* /usr/lib64
ln -sv bash /bin/sh

задать все те мелочи что мы делали прежде:
 Консоль:

export BUILD32="-m32"
export BUILD64="-m64"
CLFS_TARGET32="i686-pc-linux"
CLFS_TARGET="x86_64-Phoniex-linux"

ну и прибить это всё гвоздями к учётной записи пока ещё единственного пользователя:
 Консоль:

cat >> ${CLFS}/root/.bash_profile << EOF
export BUILD32="${BUILD32}"
export BUILD64="${BUILD64}"
export CLFS_TARGET32="${CLFS_TARGET32}"
export CLFS_TARGET="${CLFS_TARGET}"
EOF

Чтобы всё это заработало как надо, нужно создать системные декорации для root'а и системы сборки:

 Консоль:

cat > /etc/passwd << "EOF"
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:/bin:/bin/false
daemon:x:2:6:/sbin:/bin/false
messagebus:x:27:27:D-Bus Message Daemon User:/dev/null:/bin/false
nobody:x:65534:65533:Unprivileged User:/dev/null:/bin/false
EOF

cat > /etc/group << "EOF"
root:x:0:
bin:x:1:
sys:x:2:
kmem:x:3:
tty:x:5:
tape:x:4:
daemon:x:6:
floppy:x:7:
disk:x:8:
lp:x:9:
dialout:x:10:
audio:x:11:
video:x:12:
utmp:x:13:
usb:x:14:
cdrom:x:15:
adm:x:16:
input:x:24:
messagebus:x:27:
mail:x:30:
wheel:x:39:
nogroup:x:65533:
EOF


touch /var/log/{btmp,faillog,lastlog,wtmp}
chgrp -v utmp /var/log/{faillog,lastlog}
chmod -v 664 /var/log/{faillog,lastlog}
chmod -v 600 /var/log/btmp

А теперь объявляем себя Государем Мира!

 Консоль:

exec /tools/bin/bash --login +h

и увидим скромное:

 Консоль:

root:/#

Т.к. ранее был собран минимальный набор системных функций, то простейшие команды уже доступны и можно смело перемещаться по системе.

Тут нужно оговориться - я собираю всё в специально организованном загончике, но можно всё делать и по живому, например в /tmp.
Делаем cd /tmp, распаковываем нужный исходник, например unxz /sources/gettext-0.21.tar.xz, переходим в него и собираем.
Все нужные опции можно подсмотреть в ветке Temporary-System тут https://gitlab.com/Gramozeka/kokoro/-/tree/master/ . Все программы из второго списка собираются в /tools, а после входа в чрут, туда же дособираются и эти :

gettext
bison
perl
Python
multiarch_wrapper
texinfo
util-linux
vim

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

linux-5.8.9
man-pages-5.08
glibc-2.32
tools-prep
link-glibc-32
zlib-1.2.11
bzip2-1.0.8
xz-5.2.5
zstd-1.4.5
file-5.39
ncurses-6.2
readline-8.0
m4-1.4.18
bc-3.1.5
flex-2.6.4
binutils-2.35
gmp-6.2.0
mpfr-4.1.0
mpc-1.2.0
isl-0.22.1
attr-2.4.48
acl-2.2.53
libcap-2.43
shadow-4.8.1
gcc-10.2.0-final
pkg-config-0.29.2
ncurses-6.2-final
sed-4.8
psmisc-23.3
gettext-0.21
bison-3.7.2
binutils-2.35_i686
grep-3.4
bash-5.0
libtool-2.4.6
gdbm-1.18.1
gperf-3.1
expat-2.2.9
inetutils-1.9.4
perl-5.32.0
XML-Parser-2.46
intltool-0.51.0
autoconf-2.69
automake-1.16.2
kmod-27
elfutils-0.181
libffi-3.3
openssl-1.1.1g
Python-3.8.5
re2c-2.0.3
ninja-1.10.1
meson-0.55.3
coreutils-8.32
check-0.15.2
diffutils-3.7
gawk-5.1.0
findutils-4.7.0
groff-1.22.4
grub-2.04
less-551
gzip-1.10
iproute2-5.8.0
kbd-2.3.0
libpipeline-1.5.3
make-4.3
patch-2.7.6
man-db-2.9.3
tar-1.32
texinfo-6.7
vim-8.2.1361
eudev-3.2.9
procps-ng-3.3.16
util-linux-2.36
e2fsprogs-1.45.6
sysklogd-1.5.1
sysvinit-2.97
libseccomp-2.5.0
iana-etc-2.30
libsigsegv-2.12
pcre-8.44
cpio-2.13
gc-8.0.4
gpm-1.20.7
libatomic_ops-7.6.10
lsb-release-1.4

После сборки shadow нужно задать пароль рута, после сборки bash который /bin/bash(не забыли, у нас есть ещё и /tools/bin/bash) нужно войти в новый баш, и продолжать уже из него...
Важная тонкость - есть такой пакет libffi, отвечает за интерфейсы программных вызовов при работе с процессором, так вот по умолчанию у неё стоит флаг сборки --with-gcc-arch=native, т.е. она собирается под тот процессор, который сейчас реально собирает, и если мы попытаемся перенести всю собранную систему на другое железо, с другим процессором(пусть даже и того же вендора), то есть большой шанс словить "Illegal Operation Errors" и полностью неработающую систему, чтобы это избежать нужно либо явно указывать архитектуру на которой в последствии всё это будет работать, либо выставлять некие виртуальные усреднения ака x86_64. Подробности читать тут - https://gcc.gnu.org/onlinedocs/gcc-10.2 … tions.html
...
Список дан в той последовательности, в которой он гарантированно соберётся, без конфликта зависимостей,цифры дело временное, на момент написания этого поста этот набор был собран и проверен, система загрузилась штатно, без костылей и примочек, можно собирать любой собственный софт по задачам.
Да-да, про ядро и настройки ни слова  ag .
Это отдельное лютое шаманство.
Когда вот это всё собрано, собственно и наступает момент истины, насколько мы вообще представляем "как это работает".
Последовательность действий такова:
Сперва нужно выйти из системы в материнскую систему и войти обратно явно указав использовать /tools/bin/bash, это нужно для процедуры strip, она сильно уменьшает объём занимаемого пространства, буквально в разы, да и быстродействие повышает. Чистится всё хозяйство примерно так:

 Консоль:

chroot ${CLFS} /tools/bin/env -i \
    HOME=/root TERM=${TERM} PS1='\u:\w\$ ' \
    PATH=/bin:/usr/bin:/sbin:/usr/sbin \
    /tools/bin/bash --login

 Консоль:

/tools/bin/find /{,usr/}{bin,lib,lib64,sbin} -type f \
   -exec /tools/bin/strip --strip-debug '{}' ';'

Сообщения :
File format not recognized
игнорируем, это значит что файл либо сценарий оболочки, либо служебный конфиг.
После можно ещё выполнить :
--strip-all

 Консоль:
/tools/bin/find /{,usr/}{bin,sbin} -type f \
   -exec /tools/bin/strip --strip-all '{}' ';'

   
но это уже на собственное усмотрение, один момент - не стоит делать --strip-all для
библиотек(в lib,lib64) это может привести к неработоспособности системы...
Выходим снова в хост-систему:
 Консоль:
logout

и входим в уже полностью сформированную новую систему:
 Консоль:
chroot "$CLFS" /usr/bin/env -i          \
    HOME=/root TERM="$TERM"            \
    PS1='(clfs chroot) \u:\w\$ '        \
    PATH=/bin:/usr/bin:/sbin:/usr/sbin \
    /bin/bash --login

, а теперь само шаманство...
Сперва нужно построить всё в /etc
Есть уже подготовленный минимум для SysVinit лежит тут http://www.linuxfromscratch.org/lfs/dow … 818.tar.xz
Нужно распаковать архив в в нём выполнить make install безо всего.
Затем необходимо настроить udev, там много чего можно сделать, самое простое :
 Консоль:

bash /lib/udev/init-net-rules.sh

Затем сеть, в каноническом SysVinit это имеет свою специфику, подробно описано тут - http://www.linuxfromscratch.org/lfs/vie … twork.html
Все инициирующие скрипты и настройки описаны тут - http://www.linuxfromscratch.org/lfs/vie … usage.html
Настройка глобального профиля баш целая наука, минимум описан тут - http://www.linuxfromscratch.org/lfs/vie … ofile.html , http://www.linuxfromscratch.org/lfs/vie … putrc.html , http://www.linuxfromscratch.org/lfs/vie … hells.html

Когда всё это сделано собственно остаётся только собрать своё ядро, установить загрузчик и всё, система готова. Правда она ещё ничерта не может, ни сеть толком, ни всяких гитов и иксов, но это уже другая глава, где нужно решать вопросы с пакетной системой, стратегический план построения системы, что нужно, а что не очень, как автоматизировать те или иные процессы и т.д.. Частично это описано тут - http://www.linuxfromscratch.org/blfs/view/svn/, но далеко не всё, тут уже личная квалификация рулит и педалит. Я конечно это всё решил по своему и сейчас пишу из вот этого всего, есть проект моих портянок, скорее всего через какое-то время(до месяца, возможно и дольше) я залью свой набор готовой системы под вот это ядро - https://gitlab.com/Gramozeka/kokoro , но это процесс не быстрый, так что придумывайте без меня, задавайте вопросы, что знаю подскажу.
*** Добавлено: 30.09.2020 03:39:24 ***

*********
отдельно про multiarch_wrapper.
Т.к. у нас мультилиб, встаёт вопрос - как сепарировать библиотеки и бинарники разных битностей.
Вот это multiarch_wrapper для того и нужен. Если библиотеки можно разнести по lib32 и lib64, то с бинарниками это всё сложнее, потом, когда система уже собрана, это всё решается в индивидуальном порядке, я например всю ветку 32-бит вынес в отдельный анклав в корне /i686 со своим системным деревом, практически контейнер аль-ля docker, но на этапе сборке это всё не так просто.
Работает он (multiarch_wrapper) очень просто, кто секёт в ссях может почитать сам:

#define _GNU_SOURCE

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

#ifndef DEF_SUFFIX
#  define DEF_SUFFIX "64"
#endif

int main(int argc, char **argv)
{
  char *filename;
  char *suffix;

  if(!(suffix = getenv("USE_ARCH")))
    if(!(suffix = getenv("BUILDENV")))
      suffix = DEF_SUFFIX;

  if (asprintf(&filename, "%s-%s", argv[0], suffix) < 0) {
    perror(argv[0]);
    return -1;
  }

  int status = EXIT_FAILURE;
  pid_t pid = fork();

  if (pid == 0) {
    execvp(filename, argv);
    perror(filename);
  } else if (pid < 0) {
    perror(argv[0]);
  } else {
    if (waitpid(pid, &status, 0) != pid) {
      status = EXIT_FAILURE;
      perror(argv[0]);
    } else {
      status = WEXITSTATUS(status);
    }
  }

  free(filename);

  return status;
}

работает это так:
имеем приложение uasya_hakir под обе архитектуры( т.е. два бинарника с одинаковым названием, но разной битности). То, что на 32-bit переименовываем в uasya_hakir-32, а то что на 64-bit в uasya_hakir-64. Теперь создаём ссылку uasya_hakir на скомпилированный бинарник multiarch_wrapper.
И ??? Объявляем глобальную системную переменную USE_ARCH в двух видах : USE_ARCH=32 и USE_ARCH=64. Теперь, чтобы запустить 32-х битный вариант uasya_hakir , вызываем его так :

 Консоль:

/$ USE_ARCH=32 uasya_hakir

или, если нам нужна 64-х битная версия то :

 Консоль:

/$ USE_ARCH=64 uasya_hakir

или вообще :

 Консоль:

/$ uasya_hakir

т.к. по умолчанию принята 64-bit архитектура. Врапер подменяет продолжение имени ссылки на необходимую цифру и вызывает это полное имя. Это нужно для двухголового питона и перла, на этапе сборки основной системы, подробней как я это устроил смотрите в скриптах на кокоро.
*** Добавлено: 30.09.2020 22:44:06 ***

+

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

16 (30.09.2020 23:06:56 отредактировано gramozeka)

О! Нашёл где эта кнопка! Наконец-то.
Про зависимости...
Что нужно об этом знать? Главное - это не страшный зверь. Это вообще не проблема, с технической точки зрения.
Что это и как работает.
Когда кто-то пишет прогу, то учитывая, что этим занимается куча народу, он реально переизобретает лисапед, украденный, проданный и снова украденный. Поэтому, часто, какие-то отработанные решения просто включаются в код в виде готовых библиотек. И тут есть несколько тонкостей.
В каждом проекте все зависимости определены и секретом не являются, т.к. это прямой функционал проекта. Они бывают простыми, сложными, и... кольцевыми.
Простые они на то и простые - проге А нужна прога Б, точка. Тут нет проблем почти никогда.
Сложные, это когда Проге А нужна прога Б, но не просто Б, а Б собранная с зависимостью от проги С... Тут иногда просто улетает гора времени на собирание этого зоопарка.
А вот с кольцевыми зависимостями бывает самый настоящий цирк.
Для примера приведу такой пример:
Эволюшен (гномерская прога) нужен SASL... но не простой, а с LDAP, но не с просто LDAP, а с LDAP c SASL... которым нужен KERBEROS... собранный... с с LDAP, но не с просто LDAP, а с LDAP c SASL...
т.е. по сути четые проекта тупо кружат какой-то краковяк без трусов!
Но это всё страшно только на первый взгляд, есть алгоритм сборки таких танцев, сперва все части собираются с принудительно отключенными(в конфигуре всё настраивается) зависимостями, а потом каждая собирается по одной, последовательно включая необходимое, а когда все получили номинальные зависимости, то последний раз уже собираются все подряд, именно для этого в генте есть make world, когда неучтённые зависимости автоматически активируются при сквозной сборке всех уже собранных.
*** Добавлено: 01.10.2020 03:37:10 ***

Другой вариант зависимостей - это протухшее оносамое мамонта.
Это показатель вообще адекватности команды проекта и прямое указание на проработку вопроса - "а нужно ли иметь дело с этим?"
Суть очень проста - например, в программе заявлена обязательная зависимость от какой-нибудь супер-плюшки, но когда мы идем в официоз этой плюшки, то вдруг выясняется, что последние признаки жизни проект подавал в ...2002 году! и собирается только на gcc четвёртой версии... но, упоротость разработчиков не позволяет им взять уже этот проект под себя или переписать ту часть своего кода, которой нужно это застывшее ГЭ. Я стараюсь к подобному даже не прикасаться, всегда есть альтернатива, а упорствовать в глупости - поистине глупость в квадрате.

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

17 (16.10.2020 13:04:43 отредактировано gramozeka)

https://i.ibb.co/yW9BVmL/2020-10-16-14-49-18.png https://i.ibb.co/B6p9RSm/2020-10-16-14-41-53.png https://i.ibb.co/fDtK92G/Screenshot-20201016-143736.png
у-фф... обновился.
Плазма порадовала, бегает шустро и память не грызёт. Время покажет хотя.. Но первые впечатления - весьма положительны.
Займусь "приборкой" и возможно к концу месяца залью в гит, для истории. Новый метод разделения архитектур отработал - работает, теперь надо осмыслить это всё и запротоколировать... Получилось полностью построить 32-бит(ака i686-pc-linux) из x86_64 гибрида.
100% качество изображения:
https://i.ibb.co/HKdd0cH/Screenshot-20201016-150329.png

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

18

... чтоб не забыть.
Когда минимальный набор мультилиб готов, я собрал "обычный" набор софта, иксы там, всякие гномы-кеды,.. примерно с 800 пакетов. Я создал снова безликого юзера без прав, активировал режим linux32(есть такая плюшка util-linux) создал глобальную переменную MACHTYPE=i686-pc-linux, и повторил сборку кросс-тулза только уже в отдельный каталог(обошёлся без chroot, но с ним было бы проще имхо), а потом, уже стандартно от рута собрал всё необходимое из 32-битного стека для вайна, впрочем, можно и целиком систему так собрать, но она мне не особо то нужна(хотя как опция полезно).
  В итоге провозился две недели со всем этим, зато своё, посконное, из говна и палок с синей изолентой))) .

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

19 (16.10.2020 17:07:46 отредактировано shtoom)

Благодарствую за разжевывание темы! У меня аж кое-где  зазудело и ручонки  зачесались. bp Зима долгая - может и осилю наконец сборку. az

20 (16.10.2020 18:41:10 отредактировано gramozeka)

//PS//
...билась нечисть грудью в груди и друг дружку извела...

По поводу некоторых тонкостей с правами. Гном в этом отношении самый привиреда. Суть в следующем - есть несколько чувствительных точек :
папки PolKit, директория /tmp, SUID-биты на некоторые проги и права на "домашние" папки DM например GDM/SDDM/LXDM, ну и групповые политики доступа "к телу",например ни один DM не даст запустить сессию, если юзер не состоит в группе video, хотя в явном виде этого нигде не прописано, просто так дано в исходниках.
Правила PolKit будит реализованы демоном только в том случае, если каталог с ними и сами правила принадлежат пользователю polkitd и его же группе.
/tmp должна имет права 777 (chmod 777) и перед первым запуском желательно всё от туда удалить, а потом назначить права.
GDM(и остальная компания) базируются в /var/lib/<имя-рек>, права на них должны принадлежать соответствующему пользователю и его группе(вариант группа root, но не всегда работает корректно). это же относится и к логам! ака /var/log/<имя рек>, если у GDM нет доступа к /var/log/gdm, то он не сможет вернуть return 0 и упадет при старте, это нужно отслеживать.
Суид биты тёмный лес, суть в том, что запускаемый процесс имея полномочия в системе(порой почище рута), тем не менее принадлежит пользователю который его запустил, к слову сам пользователь вообще может не иметь даже оболочки, тонкая материя, могу только посоветовать читать доки на конкретные вещи полкит, пам, дбас, иксорг, мускуль, гдм и т.д.. к примеру права на xorg(X) 4755, позволяют пускать иксы от обычного юзера, а 755 уже только от рута(или наоборот?! чёт я сам запуталсо, короче разбирайтесь с этими вопросами внимательно!).
*** Добавлено: 17.10.2020 21:20:54 ***

Готово. https://gitlab.com/Gramozeka/kokoro
Можно в архив, если вдруг кто решится пройти по этому тернистому пути - то лучше Ubuntu или какая федора, чем вот это вот всё. Созданием данного проекта я не преследовал никаких амбициозных целей, чистейший, незамутнённый интеллектуальный анонизм для убийства времени... с тем же успехом можно "Войну и мир" перечитывать в издании 1908 года. да. ar

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22

21

Здравствуйте Я занимаюсь "Реставрацией" одного старого и заброшенного дистрибутива до недавнего времени всё шло более менее гладко обновил около 300 пакетов (минеральный набор программ для самостоятельной работы дистрибутива. Консольные утилиты, компиляторы...) немного поправил систему сборки пакетов, пакетный менеджер и программу установки дистрибутива (Всё сам описное). Но вот наткнулся на такую проблему которую никак в одиночку не могу победить, а именно собрать LiveCD. Поскольку родная система сборки LiveCD сломана я решил написать свой простой скрипт для сборки. Вот что я смог добиться
1) Скрипт скрипт подготавливает рабочие каталоги
2) Из указанного репозитория по списку устанавливает систему во временную папку для корневой файловой системы после чего упаковывает его в rootfs.sfs утилитой mksquashfs
3) Создаётся initrd
4) Подготовленный rootfs.sfs initrd ядро загрузчик упаковывает в iso образ

Вот на третьем этапе у меня проблема собранный initrd никак не находит rootfs.sfs

P. S. понимаю данная затея не совсем LFS но я уже не знаю куда обратится

22 (14.01.2021 13:51:38 отредактировано gramozeka)

007exe пишет:

Вот на третьем этапе у меня проблема собранный initrd никак не находит rootfs.sfs

007exe пишет:

3) Создаётся initrd
4) Подготовленный rootfs.sfs initrd ядро загрузчик упаковывает в iso образ

по порядку цитат.
первое, как пример(на самом деле, если забить в поиск "github livedvd linux", то вывалит просто море проектов) https://github.com/Tomas-M/linux-live (официальный сайтик его https://www.linux-live.org/#explore ), чем удобен конкретно этот проект, так тем, что он самодостаточен и не требует дополнительных телодвижений после создания модели системы(ака "1", "2"). Он сам создаст необходимые каталоги и структуры, а потом и сам образ, единственная забота - контролировать размер желаемой системы, образ больше чем 3-5 гигов сложновато запихнуть в озу меньше 8гиг. Но это чистая вкусовщина, каждый суслик агроном, тут советы фоном.
...
а вот вторая и третья цитата... хм?!
Тут нужно разбираться по цепочке.
Первое - нужно́ понимание всего процесса. Итак, после передачи биосом управления в загруженный образ инитрам, что происходит? А ровно то же, что и при обычной(с диска) загрузке, образ, имея на борту полноценную файловую систему(пусть и виртуальную) с уже размещёнными в ней системными утилитами и !внимание! ядерными модулями, скриптами в виртуальном /etc , и прочими прибамбасами, обеспечивающими собственно нормальную загрузку.
Второе - Вот это вот всё, когда отработает, представляет собой самодостаточную систему линукс в режиме init 1(rescue), загруженной в оперативу. После этого, собственно отрабатывает её штатный init, ну или systemd на предмет монтирования файловой системы(как частный случай расшифровке шифрованных разделов или монтированию LVM) с диска и передаче управления уже системе на нём(по сути мы имеет дважды загружаемую систему, но с разным стартовым набором)... но конкретно в твоём случае этот момент должен инициировать монтирование не с физического диска, а из той самой виртуальной системы, где находится твой rootfs.sfs, либо! должен каким-то образом(через юниты или скрипты) выполняться поиск среди доступных физических носителей именно твоего rootfs.sfs, либо по UUID, либо по метке, либо по прямому указанию и уже монтированию его, скорее всего через loop что-то-там...
  Так вот где-то в этом месте у тебя отсутствует один из этих моментов.
В предложенном выше проекте с гитхаба, который по сути набор баш-скриптов, посмотри внимательно как это всё обыгрывается, страшного там ничего нет, нудновато - да, но не очень уж заумно.
Я этими вещами уже давненько не игрался, маразм своё берёт и деталей уже не вспомню, но копать нужно как-то так.
И да, рекомендую, для облегчения всего процесса использовать федоровский dracut - http://www.bog.pp.ru/work/dracut.html (по русски, для втягивание в понимание процесса, вот оригинал -  https://dracut.wiki.kernel.org/index.php/Main_Page )

" si contuderis stultum in pila quasi tisanas feriente desuper pilo non auferetur ab eo stultitia eius " © Proverbs 27:22