Gentoo, ошибка при сборке трудоёмкого пакета, можно ли продолжить с момента сбоя?

Ну а система когда изначально установлена была?

по умолчанию при сборке portage детектит старые пути и врубает режим совместимости

В каком смысле детектит/врубает? В make.conf PORTDIR прописан же.

года 2 назад

PORTDIR устарел в пользу repos.conf

Удали его из make.conf

Тут хз. Я не помню точно когда произошёл переход в новое местоположение. Может и в пределах 2х лет, хотя мне казалось, раньше.

Не дела ради, любопытства для…

PORTDIR устарел в пользу repos.conf

хм, в дефолтном stage3 сейчас так:

# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
COMMON_FLAGS="-O2 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"

# NOTE: This stage was built with the bindist Use flag enabled
PORTDIR="/var/db/repos/gentoo"
DISTDIR="/var/cache/distfiles"
PKGDIR="/var/cache/binpkgs"

# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C

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

Так ведь repos.conf в дефолте нет.
У меня есть, но я там оверлеи прописывал. Но точно уже не помню, при каких обстоятельствах оно у меня возникло.

Как это нет? Куда делся?

вот содержимое /etc/portage/ из stage3

итого 16K
-rw-r--r-- 1 root root  591 июл  1 01:25 make.conf
lrwxrwxrwx 1 root root   59 сен  3 23:52 make.profile -> ../../var/db/repos/gentoo/profiles/default/linux/amd64/17.1
drwxr-xr-x 2 root root 4,0K июл  1 01:25 package.use
drwxr-xr-x 2 root root 4,0K июл  1 01:18 repo.postsync.d
drwxr-xr-x 3 root root 4,0K июл  1 01:10 savedconfig

Ну охренеть теперь…

Сколько у тебя оперативки? Если 8 Гб, то о -j6 можешь забыть для qtwebengine (для 16 Гб скорее всего тоже). Если 4 Гб, то можешь собирать в 2 потока, замочив DE и то в swap будет лезть.

Можно ли как заставить portage собирать из директории /var/tmp/portage с момента остановки?

например, так

ebuild /usr/portage/dev-qt/qtwebengine/qtwebengine-5.15.2_p20210824.ebuild compile merge

Но он продолжит с настройками -jX, с которыми начинал.

блин, я его в мае с -j6 на 4гб оперативки и зрамом таки собрал! Его испортили совсем?

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

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

В том смысле, что если PORTDIR из /etc/portage/make.conf после апдейта удалить - ничего до следующего апдейта не сломается

блин запустить сборку на моем 4 ядерном 3.2 ггц томогочике 5 летней давности чтоли :)
как раз есть один старый ssd на 120гб с сильно просевшим ресурсом на запись IOPS там проседает времена сильно :)
firefox из сорцов на венде собирается за часа 4 тут, помню как собирал его на ноутбуке на линуксе лет так 8 назад за 40 минут с 5200rpm HDD, вот что ваш rust творит!

Я был уверен что бутстрапная версия GCC идёт в пакете вместе с исходниками.

Под любую ось, libc и процессор?

Чтобы можно было собрать его даже если в системе нет компилятора.

В unix-подобной системе это нештатная ситуация

вот что ваш rust творит!

С растом вроде быстрее стало собираться. По крайней мере на момент перехода мне так показалось.

Под любую ось, libc и процессор?

Ну да, согласен, глупо…

Рекомендую запустить сборку parawiew. Он дольше qtwebengine собирается, емнип.

Скажи если несложно. Orange PI 4 может 4к youtube?

Когда мало оперативной памяти, можно ли компиляцию GCC из исходников разбить на этапы?

Когда мало оперативной памяти, можно ли компиляцию GCC из исходников разбить на этапы?

Так мало, что даже с -j1 не влазит? Тогда никак, иначе уменьшать параллелизм (через кастомный environment для пакета)

На панфросте без тормозов я не смог.

Даже на на одном (-j1) через часов 5 весь swap выбирается(забивается) и сборка прекращается

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

Какие use-флаги у gcc? Я смотрю, по-умолчанию включен pch, попробуй его выключить.

Компиляция с -j1 обычно немного жрет. А вот линковка чего-нибудь реально большого - это да, там можно знатно на оперативку присесть. И вот это никак не оптимизируется(можно попробовать другой линковщик, но чудес ждать не стоит).

Звучит как будто ты /var/tmp в tmpfs держишь

Хотя при реально маленьком объеме оперативки, 5 часов там бы компиляция не продержалась - всё бы засралось гораздо раньше

О каком объеме оперативки идет речь?

А сколько памяти? Гига для gcc пока что точно хватает.
Выключить LTO.
Ещё -pipe убрать попробовать

Гига для gcc пока что точно хватает.

Это в один поток?

угу

c 2гб оперативы недавно в 8 потоков собирал на восьмиядерной приставке, зрам помог.

Ещё -pipe убрать попробовать

Рубрика вредных советов?

А вот линковка чего-нибудь реально большого - это да, там можно знатно на оперативку присесть.

Если что-то большое с дебагом и без -gsplit-dwarf, то запросто, в другом случае трудно представить, откуда может появиться гигабайтный бинарник, способный заставить линкер съесть всю память

Старый boost(в районе 1.50 кажется, давно это было) у меня как-то не собирался на машине с 512M оперативки, падал именно на этапе линковки по причине нехватики памяти. Результирующие бинари либ там далеко не по 500 мегабайт, но шаблонный код видать сильно взрывает мозг линкеру, других идей почему это происходит у меня нет - я не настолько хорошо знаю потроха C++

Когда шаблон инстанцируется с разными параметрами, то для каждого набора параметров генерируется свой набор символов (т.е. каждый метод, v-таблица и т.п. имеют отдельный символ для каждого варианта параметров шаблона). Линкер про С++ ни сном, ни духом не ведает и считает, что это все разные сишные функции/переменные. В результате таблица символов может стать сильно больше, чем для нешаблонного кода, и это существенно замедляет линковку (кстати, этот эффект послужил мотивацией для создания ld.gold). Чтобы уменьшить масштаб проблемы С++ код рекомендуется собирать с -fvisiblity=hidden -fvisibility-inlines-hidden, что позволяет шаблонные символы по максимуму прятать внутри so’шек и бинарников.

Я всегда думал, что это влияет только на производительность, но не на память. Выходит, 512 метров это наверное уже слишком мало для проявления таких «квантовых эффектов» :) Мб boost тогда собирался без -fvisiblity=hidden -fvisibility-inlines-hidden (кстати в генте не стесняются калечить cflags, выставленные апстримом)

А ещё помогало '-Xlinker --no-keep-memory' в CFLAGS/CXXFLAGS или '--no-keep-memory' в LDFLAGS, в зависимости от системы сборки.