Неясные проблемы с компиляцией и установкой ПО (железо или что то еще...)

[unax]

Товарищи, здравствуйте. Уже не раз бывали всякие проблемы с компиляцией, вызывавшие приступы танцев с бубном.
И все таки сейчас некая неведавая... Может кто подскажет чего.
Ставлюсь тут на один не особо выдающийся компик с LiveDVD. Алгоритм весьма классический и многократно апробированный.
Железо: Intel Celeron D 351 3.2 ГГц, ОЗУ 512 mb (одна планочка)
Вообщем прям из под LiveDVD пересобираю всякие linux-headers, glibc, binutils, gcc-config, gcc...
Так вот присборке gcc вылетает ошибка О_о какая-то..
Думаю, ладно ядро водружу потом всю основную начинку пересобиру.
Ядро ставлю - скачалось распаковалось, и потом долго делает чего-то

Код: Выделить всё

>>> Installing (1 of 1) sys-kernel/gentoo-sources-2.6.35-r5

а потом пишет

Код: Выделить всё

Убито

хотя при успешном окончании совсем другое должно писать.
Так вот ядро не доставлено.. собрать его не получается.
В make.conf вроде все нормально:

Код: Выделить всё

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe -mfpmath=sse -mmmx -msse2 -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"

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

[/dev/random]

Приведите версию ядра, из-под которого ставите, вывод free, df и df -i, а также полный лог проваленной установки исходников ядра.

[unax]

Приведите версию ядра, из-под которого ставите, вывод free, df и df -i, а также полный лог проваленной установки исходников ядра.

Буду завтра продолжать препарировать эту железяку, и на эти вопросы отвечу.
Пока планирую исключать свои предположения, докинув планочку ОЗУ и перегнав /usr/src на другой раздел..

[megabaks]

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

[unax]

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

"я бы этому дяде с большими ушами..." ©
Ага точно... просто swap-у накинул, и вырубил все лишнее на лайв генте.. И все завелось

[DaemonTux]

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

"я бы этому дяде с большими ушами..." ©
Ага точно... просто swap-у накинул, и вырубил все лишнее на лайв генте.. И все завелось

[lormode]
буду краток. live DVD не нужен.
[lormode]

[denel]

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

"я бы этому дяде с большими ушами..." ©
Ага точно... просто swap-у накинул, и вырубил все лишнее на лайв генте.. И все завелось

А еще makeopts можно было на 1 переключить, 2 означает, что одновременно будет компилироваться 2 потока, а не один, а значит - ресурсов на компилирование соответственно уходит, проц и ОЗУ в частности.

[megabaks]

вот проц как раз и надо грузить в дофига потоков- иначе офигеешь ждать пока сообразит

[/dev/random]

вот проц как раз и надо грузить в дофига потоков- иначе офигеешь ждать пока сообразит

Только если многоядерник. У одноядерника от многопоточности профит ~10%, засчёт того, что пока один поток ждёт диск, второй работает. На практике этой разницы не заметно, и даже наоборот, из-за того, что система будет чаще лезть в своп, время может увеличиться.

[denel]

вот проц как раз и надо грузить в дофига потоков- иначе офигеешь ждать пока сообразит

Даже если ОЗУ на 2 потока маловато? до 1ГБ я думаю стоит использовать один поток, иначе временами свопинга не оберешься.
PS эта опция не определяет как грузить проц или ОЗУ, а определяет количество одновременно компилируемых потоков, а из этого вытекает жестко: Проц, ОЗУ, Диск, причем последнее просто не критично.

[DaemonTux]

1ГБ я думаю стоит использовать один поток, иначе временами свопинга не оберешься.

Бред. Можно хоть 5 потоков. Компилятор не на столько много памяти есть.

[/dev/random]

Бред. Можно хоть 5 потоков. Компилятор не на столько много памяти есть.

Вы когда-нибудь пробовали собрать openoffice?

[unax]

неее... если что-то большое собирать 5 потоков на одноядерный проц это слишком.

[DaemonTux]

Бред. Можно хоть 5 потоков. Компилятор не на столько много памяти есть.

Вы когда-нибудь пробовали собрать openoffice?

Да и не раз

неее... если что-то большое собирать 5 потоков на одноядерный проц это слишком.

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

[/dev/random]

Но и Гига должно хватить на 5 потоков. При условии, что не запущенно куча приложений жрущих память

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

[unax]

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

[офтоп] хромиум вообще удивил) я первый раз думал что из этой горы исходинков он мне скомпилит ОСь какую-нибудь гугловую [/офтоп]

[DaemonTux]

Но и Гига должно хватить на 5 потоков. При условии, что не запущенно куча приложений жрущих память

На большинстве ебилдов - да. Но при компиляции (точнее, при линковке) опенофиса, хромиума и других монстров лично у меня даже один поток глубоко в своп уходит.

Не замечал у себя токого.

[Иван Шихалев]

Про Хромиум и других монстров сразу не скажу, а про OOo точно помню, что в ебилде принудительно ставится однопоточная компиляция.

[taaroa]

Про Хромиум и других монстров сразу не скажу, а про OOo точно помню, что в ебилде принудительно ставится однопоточная компиляция.

Код: Выделить всё

$ grep -A2 'src_compile' /usr/portage/app-office/openoffice/openoffice-3.2.1.ebuild
src_compile() {

        make || die "Build failed"

...где?

click me

[/dev/random]

Про Хромиум и других монстров сразу не скажу, а про OOo точно помню, что в ебилде принудительно ставится однопоточная компиляция.

Так было раньше. Сейчас это заменили уведомлением:

Код: Выделить всё

        ewarn
        ewarn " Also if you experience a build break, please make sure to retry "
        ewarn " with MAKEOPTS="-j1" before filing a bug. "
        ewarn