iZEN

Вот только у меня не 1 ГБ ОЗУ

ну дык что трепаться-то тогда? На 8и гигах и венда свопится не будет. Можете продолжать рассуждать о прелестях своей чудной системы, и своего чудного свопа. (я кстати уже выше написал для ТС совет купить второй гиг)

При чём здесь 12309, это свопинг банальный.

ну дык что трепаться-то тогда?

8 ГБ обычно заняты на 99%. ;)

У меня такая же проблема была со сборкой фокса/хромиума.
Полечилось где-то в 3.2.x ядрах.
P4-3Ghz / 2Gb.

Собираю на старом ноутбуке с celeron 540, 1.8 Ghz + 1 gb ram - около 2 часов и не понимаю о каких 3 часах после компиляции вы говорите. Swap 1gb + j2

iZEN

8 ГБ обычно заняты на 99%. ;)

откуда я знаю, что там у вас? хоть средства мониторинга есть?

ЗЫЖ да, собрать IceCat не получилось - ld требует почти 1200Мб, а у меня всего 1500, и четвёрокеды. Попробую иксы отключить и без них собрать...

Не, мегабакс должен сказать, что всё дело в свопе.

Фотографировал только всякие кернел-паники, да ошибки загрузки :)

Ошибки загрузки следует снимать на видео, вообще-то. Не успеешь курок нажать в нужный момент.

при этом проц почти не жрется, так что наблюдаем типичный 12309

В районе запятой ты сделал /0.

Рассказываю тебе про 12309: система нихрена не делает, ждет, пока тормознутый storage закинет очередной гиг на блин, но CPU в верхней полке. Слайдшоу, конечно же, ибо отрисовывать нечем - все полимерытакты прос*аны на то, чтобы ничего не делать.

у тебя руки просто не оттуда. man линковка man swap man make.conf

Пенёк-4, памяти всего гиг
компиляй современный софт

Лол, и он ещё жалуется на 12309.

Еще один, путающий 12309 со своппингом

причина чего, простите? уход в свап это тормоза по определению.

причина тормозов при 12309 и при уходе в своп. в процессе тормозов при сборке файрфокса своп почти чист, используется максимум 100-200м, при этом все симптомы указывают на 12309

> дублирую мысль про скатывание половины свободного софта в СГ после 2008.

В 2008 году я заметил, что программы, скомпилированные в GCC 4.2, не работают в системе с GCC 4.1. Только наоборот. Не знаешь, с GCC 3 и libstdc++.so.5 так же было?

CeleronM 1.7 x 512MiB x 60GiB-HDD. в своё время мне этого хватило чтобы всё скомпилировать и собрать lfs. сейчас проц тот же, но 4 гига оперы и всё нормально компилируется.

> ОК, я обязательно попробую выставить swappiness в 100, когда выйдет новый Firefox.

Уже вышел. 10.0.2.

>> А у нас в слаке такими вещами Патрег занимается.

не, ну почему сразу Патрег? Я собирал фф. Могу сказать, что на 512 он в принципе не соберётся

Собирал на 512 мб памяти версии 3.5 и 3.6 в убунте, что немаловажно. 40 минут.

ZenitharChampion

Собирал на 512 мб памяти версии 3.5 и 3.6 в убунте, что немаловажно. 40 минут.

причём тут 3.6?

--no-keep-memory

+1

Непонятна суть поста. По моему все нормально. На нетбуке 10 лиса собирается около 7 часов. Из которых 4 часа линковка.

>> А можно узнать , сферический в вакууме самоскомпиленный фаерфокс на самом деле быстрее? или это фантастика?

вроде тоже самое. Хотя наверное можно попробовать всякие опции. Вообще именно ФФ собирать ИМХО нет смысла, бинарники с сайта или от Патрега ничем не хуже

Только по скорости. Бинарник с сайта скомпилирован с опцией использования собственной библиотеки Cairo, а не системной, и фанаты патченного Cairo злятся от этого.

>> На FreeBSD компиляция хоть в текстовой консоли, хоть в графическом терминале практически НИКАК не сказывается на отзывчивости интерфейса пользователя и на работе запущенных программ.

дык в Linux тоже не сказывается. НИКАК. Но если памяти не хватает, FreeBSD всё равно работает? Вы в сказки верите?

Памяти хватает: на скриншоте 6 Гб SWAP.

>> Во всём виноват Питон

чё?

Посмотрев на скриншот, я сразу заметил python2.7 и тоже на него подумал. А что не так?

>> вся прелесть заключается в жутком 12309 при работе ld

Еще один, путающий 12309 со своппингом

12309 возникает на некоторых компьютерах при интенсивном обмене данных с HDD, например swapping.

> ... какой-нит г-но юнити ...

Теперь понятно, откуда возмущение насчёт python: исходное сообщение не прочитано, то, что у ТС Gentoo, не знаешь.

Использовать .rpm based дистрибутивы.
Осилить yum или что там.
Профит.

Гентупроблемы.

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

Установи на генту foo-yc20-1.3.0 и почаще его компиляй и будет тебе радость.

генту
памяти всего гиг

А возможно ли такое?

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

--no-keep-memory

Пробовал?

12309 возникает на некоторых компьютерах при интенсивном обмене данных с HDD, например swapping.

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

Кроме того, компиляция мозилловских приложений на FreeBSD возможна с использованием системного LLVM/Clang 3.0 вместо традиционного GCC. Это заметно сказывается на скорости сборки приложения (примерно на 25-30% быстрее).

В линукс это тоже не запрещено. А результат по скорости как, есть сравнения в цифрах?

>> генту

памяти всего гиг

А возможно ли такое?

Gentoo не вчера появилась.

ZenitharChampion

Теперь понятно, откуда возмущение насчёт python: исходное сообщение не прочитано, то, что у ТС Gentoo, не знаешь.

причём тут пайтон-то? у меня тоже не собирается. Что очевидно - памяти 1500, а 10ка требует почти 1200 на линковке. Что, в gentoo будет по другому?

PolarFox

Гентупроблемы.

если-бы... 1200 это терпимо, а как будет 4000? Как тогда 32х битную версию ВООБЩЕ СОБРАТЬ?! А это недолго - седьмую версию я легко на гиге собирал, в иксах и с кедами.

queen3

А возможно ли такое?

а что такого? тот-же ФФ жрёт при сборке метров 80..120 памяти. а что они сделали с линковкой - я не знаю. ld тоже не вчера появилась, и вроде таких фэйлов не было. (?)

да, как-то собирал chromium на < 512Мб

--no-keep-memory
ld normally optimizes for speed over memory usage by caching the symbol tables of input files in memory. This option tells ld to instead optimize for memory usage, by rereading the symbol tables as necessary. This may be required if ld runs out of memory space while linking a large executable.

Поставить x86_64 ядро и мультилибный x86_64 binutils, собрать, профит.

да, как-то собирал chromium на < 512Мб

Просто мне показалось, что фф при сборке где-то какие-то флаги фильтрует и выставляет свои. Мне "--no-keep-memory" вроде не помогало.

У меня сборка клиентского С++ проекта жрёт 12 гиг и ей мало. Конечно, это j4, но тем не менее даже в один процесс гига будет маловато. Судя по скриншоту, в собираемом проекте тоже неслабый список модулей. Т.е. или как ТС, мучаться со свопом, или?... о том и вопрос.

rainy

--no-keep-memory

покажите, как сделать это для фф.

uzbl

Поставить x86_64 ядро и мультилибный x86_64 binutils, собрать, профит.

взлетит на 32х?

Пора пойти на барахолку и сделать «апгрейд»: даже последние p4 поддерживали x86_64.

uzbl

Пора пойти на барахолку и сделать «апгрейд»: даже последние p4 поддерживали x86_64.

мой держит. ещё и мозгов опять покупать...

LDFLAGS="--no-keep-memory" emerge firefox
или в /etc/make.conf

должно работать

Не замечал ни одного, ни другого.

Их есть у меня.

А результат по скорости как, есть сравнения в цифрах?

% cc --version
cc (GCC) 4.2.1 20070831 patched [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% time portmaster -gD --delete-build-only firefox-10.0.2,1
======================================================================

===>>> Done displaying pkg-message files

===>>> Re-installation of firefox-10.0.2,1 complete

2745.130u 325.617s 20:09.36 253.9%      7289+4392k 11796+584172io 8308pf+0w

% ls /store/pckgs64/All/firefox-10.0.2,1.tbz
-rw-r--r--  1 root  wheel    30M Feb 27 20:31 /store/pckgs64/All/firefox-10.0.2,1.tbz

% /usr/bin/clang --version
FreeBSD clang version 3.0 (tags/RELEASE_30/final 145349) 20111210
Target: x86_64-unknown-freebsd9.0
Thread model: posix

% time portmaster -gD --delete-build-only firefox-10.0.2,1
======================================================================

===>>> Done displaying pkg-message files

===>>> Re-installation of firefox-10.0.2,1 complete

1810.805u 208.605s 13:16.48 253.5%      26336+1608k 12245+408227io 33809pf+0w

% ls /store/pckgs64/All/firefox-10.0.2,1.tbz
-rw-r--r--  1 root  wheel    27M Feb 27 20:51 /store/pckgs64/All/firefox-10.0.2,1.tbz

Перед каждым тестом правился /etc/make.conf на предмет использования необходимого типа компилятора, а машина перезагружалась, чтобы не «греть» кэш ZFS. В обоих случаях помимо сборки был запущен Xorg в виде менеджера входа в систему Slim без логина пользователя в графическую оболочку.

Аппаратное обеспечение: процессор AMD Phenom II X4 810, память DDR3-1333 два модуля по 4 ГБ, жёсткий диск SAMSUNG SpinPoint M7E (HM641JI).

Я имел ввиду скорость работы браузера.