Собственно о чём речь - LFS есть на английском, нужно ли сюда(на форум) это переводить(не буквально слово в слово, а как практическое руководство к действию), кому интересно и вообще.
Сам по себе LFS это только заготовка, если погрузится в этот вопрос достаточно глубоко, то возможно создать полноценную систему, времени это занимает примерно неделю(плюс-минус) если сидеть у компа весь день и ни на что не отвлекаться. Называется это BLFS и как расширенный вариант с кросплатформенной частью CBLFS, последний отличается в корне от изначального LFS как последовательностью сборки так и некоторыми фичами.
PS/ и не стесняйтесь высказывать свои пожелания и вопросы.
LinuxForum.Fans
LFS - и все что с ней связано.
Автор: gramozeka
22 сообщений
4901 просмотров
Если хотите поделиться личным опытом, то почему и нет. :) Вам же самим будет таблетка для памяти. Лично мне интересно, но страшновато. Генты как бы хватает, но приблежается зима и кто его знает...вполне может и быть... %)
shtoom, Эх гента это очень очень сложно, LFS есче конечно сложнее :(
gramozeka, Не ну почитать будет интересно пожалуй, я за.
shtoom, Эх гента это очень очень сложно, LFS есче конечно сложнее :(
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'е, писано с нуля, не всё конечно гладко, я тот ещё кодер-индус, со временем конечно причешу и уберу лишнее, но это пока в планах.
Вот собственно так как-то... *PARDON*
Добавлено: 29.10.2017 19:20:56
Вот ссылка на сборочный конвейер, все описания в ReadMe-Now, возможно какие-то ошибки всплывут, вношу правки иногда, может кому-то и пригодится. *DONT_KNOW*
https://github.com/gramozeka/CBLFS-SemiAutomatic
githab стал некошерен, перехал на gitlab.
Вот ссылки на проект :
старый(поумирали некоторые ссылки в загрузчике, но при желании их можно найти в архивах и докачать вручную) : https://gitlab.com/Gramozeka/Genesis-cblfs
а это новый(актуален на 25.04.2019) : https://gitlab.com/Gramozeka/cross-blfs .
Загрузчика нет, пока. Но есть примерный список - по названию тарбола все ищется в гугле за секунду. все списки в соответствующих директориях. Проект сырой, но уже рабочий, пишу с него. Если у кого есть проблемы с кросс-компиляцией, в разделе https://gitlab.com/Gramozeka/cross-blfs/tree/master/BASE_SYSTEM есть два тарбола, это готовый тулкит для сборки. Распаковать в чистый раздел будущей системы и можно начинать собирать в chroot со стадии №2(в инструкции), не забудьте только исходники загрузить.
perl и python модули я гружу вручную через cpan и pip/pip3 , можно конечно заморочиться и опакетить, но слишком это трешово, для texLive перлу нужно больше 30 модулей с зависимостями, если это всё начать опакечивать можно двинутся, поэтому пока так. Wayland работает, но так и не осилил настроить weston, работает всё через... как у Потеринга в общем, да и невидия до сих пор не дружит по уму с ним. Тайминг сборки около 50 часов, но если подкрутить оптимизацию и настроить ccache то можно ускорить, я этим не занимался.
Пишите, форкайте, критикуйте, после второго инфаркта мне недолго осталось, так что может кому сгодится мозги потренировать.
после второго инфаркта мне недолго осталось
*SCRATCH* Это куда ты там намылился? А мастер-классы "на все руки мастер" кто проводить будет? o_O
Wolfenberg, Вот-вот,совсем человек совесть потерял... :)
А мастер-классы "на все руки мастер" кто проводить будет?
сами, всё сами, ищ обленились, "..во-о-от мы в ваше время !"... :D
как говорят на лоре "нинужна". Достаточно документации в /usr/share/doc{,info}(/usr/doc{,info}).
Никогда раньше внимания не обращал, а тут залез случайно и залип на месяц - это ж клондайк знаний, даже интернет не нужен, сиди читай, вся система под микроскопом.
gramozeka, Ну, нет. Будет еще инфаркт-микарда и вот такой рубец. *WRITE* :)
сами, всё сами, ищ обленились, "..во-о-от мы в ваше время !"... ag
:P Ни фига! Сам обещал показать болгарку под управлением Gentoo Linux.
после второго инфаркта мне недолго осталось
Отставить паническое настроение, надо верить в лучшее. И да 100 лет желаю вам ещё прожить. *DRINK*
хАчуу! ХАчууу болгарку! ((с) Адская белочка)под управлением Gentoo Linux.
болгарку под управлением Gentoo Linux.
o_O я тоже хочу такое увидеть, это же шедевр
Сам обещал показать болгарку под управлением Gentoo Linux.
пруфы!!
я такого не говорил, но на сие поделие бы глянул...
и таки да! Прекращайте оффтоп, давайте по существу темы.
Тут копался в wine, так обнаружил одну забавную фичу - а именно, оказывается можно построить практически аналог WoW64, для этого нужен корректный multilib и ванильный i686-based, в первом строится чистый wine-win64, во втором чистый wine-i686, потом в первом собирается гибрид wine-win64+wine-i686=wine-multilib.
В таком гибриде корректно работают проги как 32-бит, так и 64-бит, собственно как в любой 64-бит винде.
вот так выглядит дерево такого вайна:
при winecfg ошибок меньше в разы!(и да, я собираю актуальный staging с ./patches/patchinstall.sh DESTDIR=../$PRGNAM-$VERSION --all
...............
*************** ВВЕДЕНИЕ *****************
Итак дорогие мои, начнём забивание мозгов тем что "НИНУ́ЖНА".
С чего начать? Первое что приходит на ум, это как устроена система с точки зрения самой системы. Но это тупиковый путь, т.к. тема безгранична и до сути вопроса в практической плоскости данного топика можно никогда не добраться, поэтому задекларируем что мы это знаем. *WALL*
Для построения системы потребуется немного чистого диска, для знакомства хватит пяти гигов(на самом деле всего 600-800 метров, но накладные расходы на сборку и исходники...).
Потребуется система, способная собрать gcc и glibc, что на самом деле довольно не тривиальная задача.
Потребуется специально огороженный юзер.
Вот с него и начнём.
Делается он так:
[console]
groupadd clfs
useradd -s /bin/bash -g clfs -d /home/clfs clfs
mkdir -pv /home/clfs
chown -v clfs:clfs /home/clfs
passwd clfs
[/console]
вроде всё как всегда, что особенного?
Если вот прямо сейчас зайти в учётку этого юзера, то он получит все стандартные атрибуты обычного пользователя, на которые, в повседневности никто не смотрит, а тупо пользуется.
Это набор стандартных системных переменных, вот в них-то и вся соль.
Система сама их назначает из глобальных установок в /etc/profile, /etc/skell и остальных конфигураций в /etc, коих там вагон и не один.
Так вот для собирания(из исходников) кросскомпилятора gcc это всё высокотоксичный актив и от него нужно держаться подальше.
Для этого есть инструмент в самой системе - это индивидуальный профиль bash. Хранится он в `$HOME/.bash_profile и `$HOME/.bashrc. Первый инициатор этих установок, а второй - собственно установки.
Работает это так - при логине в профиль, система опрашивает домашний каталог на предмет наличия этих файлов и если они присутствуют, то глобальные настройки из /etc игнорируются.
Для нашей задачи это выглядит так:
cat $HOME/.bash_profile
text
exec env -i HOME=${HOME} TERM=${TERM} PS1='\u:\w\$ ' /bin/bash
cat ~/.bashrc
text
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
отмена флагов компилятора если вдруг таковые были где-то заявлены системой.
Собственно с этим всё. Войдя в эту учётку стоит применить :
[console]
source ~/.bash_profile
[/console]
и мы получим необходимый инструмент для дальнейшего продвижения.
..продолжение следует.
Добавлено: 29.09.2020 14:37:17
..продолжим.
Сам по себе компилятор работать не может, ему нужен определённый обвяз. Фундаментом является связка с\с++, уже на ней строится всё остальное - фортраны, бейсики и прочий зоопарк из рептилий и всяких растов.
Подробно останавливаться на том кто есть кто я тут не буду, просто перечислю что нужно:
text
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.
[console]
su -
[/console]
Сейчас все действия выполняются от root'а, пока я явно не укажу другое(п. 5)
1.
[console]
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 /
[/console]
!!! ахтунг !!! /dev/sdb2 - это пример! ставьте своё!
2.
[console]
groupadd clfs
useradd -s /bin/bash -g clfs -d /home/clfs clfs
mkdir -pv /home/clfs
chown -v clfs:clfs /home/clfs
passwd clfs
[/console]
3.
[console]
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
[/console]
!!! ахтунг !!!
Теперь нужно запастись исходниками. Можно просто шарить по сети и тупо качать, можно на сайте проекта прочитать пункт http://www.linuxfromscratch.org/lfs/view/development/chapter03/introduction.html
но есть одно "НО", я описываю создание немного более расширенной версии LFS, а именно multilib, там более жёсткие требования к среде, поэтому не всё что описано в LFS будет работать.
вот полный набор ссылок для кросс-компилятора:
1. [url]ftp://ftp.astron.com/pub/file/file-5.39.tar.gz[/url]
2. https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.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/pkgconfiglite/files/0.28-1/pkg-config-lite-0.28-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.
[console]
chown -vR clfs:clfs ${CLFS}/sources
su - clfs
[/console]
5.(!!! ахтунг !!! теперь очень важные танцы с бубной !!!) мы теперь пользователь clfs и все действия в дальнейшем выполняются от его имени, пока я явно не укажу другое!!!
[console]
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
[/console]
6.
[console]
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
[/console]
Ну вот теперь можно собирать...
продолжение следует...
Добавлено: 29.09.2020 19:28:58
Ну вот теперь можно собирать...
...ну да, ну да, собирать. Надо прояснить некоторые моменты до того как.
Есть два подхода к процессу сборки - первый самый тупой и надёжный: зайти в дерево исходника и скомандовать "ату яво! фас!", как там в фильме: "...машина надёжная, убойная, 75 патронов, но весит...", это срабатывает для маленьких наколеночных вещей ака "Hello World!", но для чего-то серьёзного это не годится(если конечно важен не просто результат, а предсказуемый и, что важнее, обратимый результат, когда всё можно обернуть взад).
Для второго нужны скрипты, как правило на баше(не обязательно). В них прописывается весь сценарий сборки целиком, задача просто запустить скрипт и он всё что нужно выполнит.
В первой иттерации пакетирование(ещё одна фишка) не нужно, всё будем делать "по живому", но таки скриптиками запастись стоит...
Добавлено: 29.09.2020 20:20:19
сама процедура проста:
распаковываем архив, заходим в него, выполняем последовательность команд:
text
./configure --prefix=/cross-tools
make -j4
make install
тут важен --prefix=/cross-tools (выше мы сделали симлинк в главном дереве системы на реальное расположение директории). Это нужно для того, чтоб готовые программы, оказавшись в изоляции, продолжали считать своё местоположение от корня.
Но это не всё, для каждого архива набор специфических установок разный. Чуть позже я залью обновлённое дерево на гитлаб, а пока просто приведу по порядку сборки для каждого архива:
file-5.39
text
./configure --prefix=/cross-tools
make
make install
linux-5.8.9
text
make mrproper
make INSTALL_HDR_PATH=dest headers_install
mkdir -pv /tools/include || true
cp -rv dest/include/* /tools/include
m4-1.4.18
text
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
text
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
text
./configure \
--prefix=/cross-tools \
--build=${CLFS_TARGET} \
--with-pc-path=/tools/lib64/pkgconfig:/tools/share/pkgconfig
make
make install
gmp-6.2.0
text
./configure \
--prefix=/cross-tools \
--enable-cxx \
--disable-static
make
make install
mpfr-4.1.0
text
LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
./configure \
--prefix=/cross-tools \
--disable-static \
--with-gmp=/cross-tools
make
make install
mpc-1.2.0
text
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
text
LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
./configure \
--prefix=/cross-tools \
--disable-static \
--with-gmp-prefix=/cross-tools
make
make install
binutils-2.35
text
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 - первый ход, предварительный. Далее директория для сборки будет создаваться вообще вне дерева исходников, для удобства.
text
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/-/blob/master/sources/gcc-10.2.0-specs-1.diff , он исправляет пути для автоматического линковщика, чтоб получившийся прекомпилятор не ломился в родительскую систему за каждой мелочёвкой, это важная примочка, но есть современные средства позволяющие получать тот же результат, но тогда надо полностью следовать путём предлагаемым в официальном руководстве и забыть о multilib.
glibc-2.32 32-бита.
text
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-бита.
text
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
Собственно первый ход кросс-компиляции, всё что выше это только прелюдия была.
text
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// об одной "мелочи" я не рассказал, это такая фича как
text
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/-/tree/master/Core/Cross-tools
Достаточно распаковать оба архива в нужное место и после небольших манипуляций можно делать chroot в полностью готовую для сборки системы среду. Она уже умеет в мультилиб, поэтому иметь какую-то продвинутую систему не обязательно, лишь бы она(система) умела в chroot, и могла в 64-битное ядро, более-менее свежее.
********************************************
продолжу описание процесса.
...после сборки gcc-10.2.0_cross, мы всё ещё сильно зависим от материнской системы, нам нужны всякие тары, сиды, перлы и прочие питоны с башами. Второй этап это создание этих всех инструментов с привязанным к ним компилятором, который будет зависим только от самого себя.
Вот нужные инструменты по порядку сборки:
text
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, добавим несколько переменных и изменим саму среду сборки:
[console]
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
[/console]
Это очень важный момент, так как в окружении пользователя глобально объявлены переменные CC, CXX и т.д., то при умолчании, скрипты configure, сперва будут искать в системе именно эти компиляторы и инструменты, а в некоторых, так и вовсе только эти переменные и отвечают за правильное обращение к сборочному процессу, а т.к. хеширование у оболочки отключено, то в первую очередь будет найден наш новый кросс-компилятор
x86_64-unknown-linux-gnu-gcc , а не системный gcc.
После объявления этих переменных, можно начинать собирать вторую часть кросс-компилятора(выше список). Подробно расписывать все 33 позиции наверно не стоит, слишком уж много места это занимает.
Подробно можно посмотреть вот тут - https://gitlab.com/Gramozeka/kokoro/-/tree/master/Temporary-System
там всё должно быть понятно, если есть желание, то немного доработав(заменив или убрав переменные скрипта) можно просто собирать вручную.
На счет "СТОП!!!!!! ЭТО ОТДЕЛЬНАЯ ПЕСТНЯ́!". Это один из тонких моментов.
Некоторые вещи, такие как perl или python, при сборке крайне неразборчивы и мало-управляемые, поэтому практически не пригодны для кросс-компиляции, т.к. собираясь, они находят в системе самих же себя установленных, и наглухо линкуются с тем, что есть, запретить это или как-то ограничить просто не реально. Поэтому, дойдя до этого места, дособирать кросс-тул придётся уже в chroot-окружении.
***************************************
Вернёмся к вопросу возможности материнской системы к собиранию мультилиба, выше ссылка на два архива, если нет возможности собрать нативный мультилиб, то можно воспользоваться уже готовым кросс-тулом, в нем уже собраны все нужные вещи, в том числе и эта пестня с питонами и перлами...
Кто-то заметил - а что за приблуда multiarch_wrapper ? В самом низу поясню зачем это.
*************************************************
... дойдя до этого места, дособирать кросс-тул придётся уже в chroot-окружении.
Для этого, собрав всё до xz включительно, нужно выйти из учетки clfs, он больше не нужен и его можно удалить из системы полностью, необходимо, оставаясь root'ом, создать в устанавливаемой системе необходимое дерево процессов ака proc, dev, var и т.д., создать ноды(что это вообще за чертовщина!?) и прочие моменты, монтируем это всё хозяйство в ядро работающей системы и выполняем chroot:
(!!!Ахтунг!!! Теперь мы root! Практически партизан в тылу врага, поэтому делаем всё очень вдумчиво и аккуратно.)
[console]
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)
[/console]
а теперь Горбатый!!!(чрутимся в наш шалашик):
[console]
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
[/console]
Выполнив это мы увидим вот такую картинку:
[console]
I have no name!:/#
[/console]
теперь мы единственный и безраздельный пользователь с безграничными полномочиями в системном пространстве будущей системы, в которой пока нет ничего, кроме пустоты.
Теперь нужно построить всё системное дерево "как у людей":
[console]
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
[/console]
задать все те мелочи что мы делали прежде:
[console]
export BUILD32="-m32"
export BUILD64="-m64"
CLFS_TARGET32="i686-pc-linux"
CLFS_TARGET="x86_64-Phoniex-linux"
[/console]
ну и прибить это всё гвоздями к учётной записи пока ещё единственного пользователя:
[console]
cat >> ${CLFS}/root/.bash_profile << EOF
export BUILD32="${BUILD32}"
export BUILD64="${BUILD64}"
export CLFS_TARGET32="${CLFS_TARGET32}"
export CLFS_TARGET="${CLFS_TARGET}"
EOF
[/console]
Чтобы всё это заработало как надо, нужно создать системные декорации для root'а и системы сборки:
[console]
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
[/console]
А теперь объявляем себя Государем Мира!
[console]
exec /tools/bin/bash --login +h
[/console]
и увидим скромное:
[console]
root:/#
[/console]
Т.к. ранее был собран минимальный набор системных функций, то простейшие команды уже доступны и можно смело перемещаться по системе.
Тут нужно оговориться - я собираю всё в специально организованном загончике, но можно всё делать и по живому, например в /tmp.
Делаем cd /tmp, распаковываем нужный исходник, например unxz /sources/gettext-0.21.tar.xz, переходим в него и собираем.
Все нужные опции можно подсмотреть в ветке Temporary-System тут https://gitlab.com/Gramozeka/kokoro/-/tree/master/ . Все программы из второго списка собираются в /tools, а после входа в чрут, туда же дособираются и эти :
text
gettext
bison
perl
Python
multiarch_wrapper
texinfo
util-linux
vim
Когда это всё собрано, можно приступать собственно к построению своей собственной системы, так, как взбредёт в голову. Есть конечно базовый минимум, который нужно построить чтобы просто удалить наши кросс-инструменты, вот примерный список :
text
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.0/gcc/x86-Options.html
...
Список дан в той последовательности, в которой он гарантированно соберётся, без конфликта зависимостей,цифры дело временное, на момент написания этого поста этот набор был собран и проверен, система загрузилась штатно, без костылей и примочек, можно собирать любой собственный софт по задачам.
Да-да, про ядро и настройки ни слова :D .
Это отдельное лютое шаманство.
Когда вот это всё собрано, собственно и наступает момент истины, насколько мы вообще представляем "как это работает".
Последовательность действий такова:
Сперва нужно выйти из системы в материнскую систему и войти обратно явно указав использовать /tools/bin/bash, это нужно для процедуры strip, она сильно уменьшает объём занимаемого пространства, буквально в разы, да и быстродействие повышает. Чистится всё хозяйство примерно так:
[console]
chroot ${CLFS} /tools/bin/env -i \
HOME=/root TERM=${TERM} PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin \
/tools/bin/bash --login
[/console]
[console]
/tools/bin/find /{,usr/}{bin,lib,lib64,sbin} -type f \
-exec /tools/bin/strip --strip-debug '{}' ';'
[/console]
Сообщения :
File format not recognized
игнорируем, это значит что файл либо сценарий оболочки, либо служебный конфиг.
После можно ещё выполнить :
--strip-all
[console]/tools/bin/find /{,usr/}{bin,sbin} -type f \
-exec /tools/bin/strip --strip-all '{}' ';'[/console]
но это уже на собственное усмотрение, один момент - не стоит делать --strip-all для
библиотек(в lib,lib64) это может привести к неработоспособности системы...
Выходим снова в хост-систему:
[console]logout[/console]
и входим в уже полностью сформированную новую систему:
[console]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[/console]
, а теперь само шаманство...
Сперва нужно построить всё в /etc
Есть уже подготовленный минимум для SysVinit лежит тут http://www.linuxfromscratch.org/lfs/downloads/development/lfs-bootscripts-20200818.tar.xz
Нужно распаковать архив в в нём выполнить make install безо всего.
Затем необходимо настроить udev, там много чего можно сделать, самое простое :
[console]
bash /lib/udev/init-net-rules.sh
[/console]
Затем сеть, в каноническом SysVinit это имеет свою специфику, подробно описано тут - http://www.linuxfromscratch.org/lfs/view/development/chapter09/network.html
Все инициирующие скрипты и настройки описаны тут - http://www.linuxfromscratch.org/lfs/view/development/chapter09/usage.html
Настройка глобального профиля баш целая наука, минимум описан тут - http://www.linuxfromscratch.org/lfs/view/development/chapter09/profile.html , http://www.linuxfromscratch.org/lfs/view/development/chapter09/inputrc.html , http://www.linuxfromscratch.org/lfs/view/development/chapter09/etcshells.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) очень просто, кто секёт в ссях может почитать сам:
text
#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 , вызываем его так :
[console]
/$ USE_ARCH=32 uasya_hakir
[/console]
или, если нам нужна 64-х битная версия то :
[console]
/$ USE_ARCH=64 uasya_hakir
[/console]
или вообще :
[console]
/$ uasya_hakir
[/console]
т.к. по умолчанию принята 64-bit архитектура. Врапер подменяет продолжение имени ссылки на необходимую цифру и вызывает это полное имя. Это нужно для двухголового питона и перла, на этапе сборки основной системы, подробней как я это устроил смотрите в скриптах на кокоро.
Добавлено: 30.09.2020 22:44:06
+
О! Нашёл где эта кнопка! Наконец-то.
Про зависимости...
Что нужно об этом знать? Главное - это не страшный зверь. Это вообще не проблема, с технической точки зрения.
Что это и как работает.
Когда кто-то пишет прогу, то учитывая, что этим занимается куча народу, он реально переизобретает лисапед, украденный, проданный и снова украденный. Поэтому, часто, какие-то отработанные решения просто включаются в код в виде готовых библиотек. И тут есть несколько тонкостей.
В каждом проекте все зависимости определены и секретом не являются, т.к. это прямой функционал проекта. Они бывают простыми, сложными, и... кольцевыми.
Простые они на то и простые - проге А нужна прога Б, точка. Тут нет проблем почти никогда.
Сложные, это когда Проге А нужна прога Б, но не просто Б, а Б собранная с зависимостью от проги С... Тут иногда просто улетает гора времени на собирание этого зоопарка.
А вот с кольцевыми зависимостями бывает самый настоящий цирк.
Для примера приведу такой пример:
Эволюшен (гномерская прога) нужен SASL... но не простой, а с LDAP, но не с просто LDAP, а с LDAP c SASL... которым нужен KERBEROS... собранный... с с LDAP, но не с просто LDAP, а с LDAP c SASL...
т.е. по сути четые проекта тупо кружат какой-то краковяк без трусов!
Но это всё страшно только на первый взгляд, есть алгоритм сборки таких танцев, сперва все части собираются с принудительно отключенными(в конфигуре всё настраивается) зависимостями, а потом каждая собирается по одной, последовательно включая необходимое, а когда все получили номинальные зависимости, то последний раз уже собираются все подряд, именно для этого в генте есть make world, когда неучтённые зависимости автоматически активируются при сквозной сборке всех уже собранных.
Добавлено: 01.10.2020 03:37:10
Другой вариант зависимостей - это протухшее оносамое мамонта.
Это показатель вообще адекватности команды проекта и прямое указание на проработку вопроса - "а нужно ли иметь дело с этим?"
Суть очень проста - например, в программе заявлена обязательная зависимость от какой-нибудь супер-плюшки, но когда мы идем в официоз этой плюшки, то вдруг выясняется, что последние признаки жизни проект подавал в ...2002 году! и собирается только на gcc четвёртой версии... но, упоротость разработчиков не позволяет им взять уже этот проект под себя или переписать ту часть своего кода, которой нужно это застывшее ГЭ. Я стараюсь к подобному даже не прикасаться, всегда есть альтернатива, а упорствовать в глупости - поистине глупость в квадрате.
у-фф... обновился.
Плазма порадовала, бегает шустро и память не грызёт. Время покажет хотя.. Но первые впечатления - весьма положительны.
Займусь "приборкой" и возможно к концу месяца залью в гит, для истории. Новый метод разделения архитектур отработал - работает, теперь надо осмыслить это всё и запротоколировать... Получилось полностью построить 32-бит(ака i686-pc-linux) из x86_64 гибрида.
100% качество изображения:
... чтоб не забыть.
Когда минимальный набор мультилиб готов, я собрал "обычный" набор софта, иксы там, всякие гномы-кеды,.. примерно с 800 пакетов. Я создал снова безликого юзера без прав, активировал режим linux32(есть такая плюшка util-linux) создал глобальную переменную MACHTYPE=i686-pc-linux, и повторил сборку кросс-тулза только уже в отдельный каталог(обошёлся без chroot, но с ним было бы проще имхо), а потом, уже стандартно от рута собрал всё необходимое из 32-битного стека для вайна, впрочем, можно и целиком систему так собрать, но она мне не особо то нужна(хотя как опция полезно).
В итоге провозился две недели со всем этим, зато своё, посконное, из говна и палок с синей изолентой))) .
Благодарствую за разжевывание темы! У меня аж кое-где зазудело и ручонки зачесались. *YAHOO* Зима долгая - может и осилю наконец сборку. *DRINK*
//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
Можно в архив, если вдруг кто решится пройти по этому тернистому пути - то лучше убунта или какая федора, чем вот это вот всё. Созданием данного проекта я не преследовал никаких амбициозных целей, чистейший, незамутнённый интеллектуальный анонизм для убийства времени... с тем же успехом можно "Войну и мир" перечитывать в издании 1908 года. да. [:}
Войдите или зарегистрируйтесь, чтобы ответить.
