[Gentoo] Сборка firefox

можно поставить бинарник
а вообще оперативы не помешает - своп это лютые термоза

Если раньше собиралось в разумное время, и при этом оперативы нехватает немного, то поможет. Если и раньше люто тупило, или стало жрать резко больше оперативки, то не вариант.

по-моему, ему для сборки требуется 4 гига свободной рамы, так что делай выводы

Куда катится мир, для сборки браузера надо больше, чем 2 гига рамы...

По сабжу - своп = тормоза, так что лучше поставить бинарник.

Ну ясно, буду память докупать.

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

Прилетело очередное обновления для огнелиса. Начал собираться и не собрался. Недостаточно памяти(2 гига + столько же свопа). Поможет ли увеличение свопа или надо докупать оперативу?

Последнее время всегда собираю firefox сам (SuSE 11.4 32bit, 2Gb, swap-раздел отсутствует). Собирается конечно долго — 45~60 минут, но никаких проблем замечено не было. Процессор нагружен почти под завязку, но памяти более чем достаточно — htop показывает занятыми ~500Mb (это вместе с запущенным софтом).

ставь bin. Или пиши в багтрекер.

Я не зря тебя спросил в другом топике. На кальке все 4 мои компа не смогли обновить firefox. Это баг. На всех машинах x86_64, с четырьмя гигами памяти.

Два гига оперативки, два гига свопа, ~amd64 - firefox-11.0-r1 (и все предыдущие версии) нормально собирается. Если у тебя в MAKEOPTS стоит большое число после -j, то уменьши его (у меня, например, там стоит -j2 как раз из-за chromium и firefox).

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

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

Какой-то у вас более другой firefox. У меня с парой десятков вкладок он только ~400 метров памяти ест. А при сборке я уже описал выше - отъедает всё.

Во время линковки chromium и firefox у меня система тоже своп кушает немножко, но не больше ста метров (при этом иксами и прочими приложениями занято что-то около 400 метров).

Что система неюзабильна во время свопинга - это не открытие.

Скажи, что ли, версию gcc, я не знаю, что ещё влиять может.

* и binutils

по-моему, ему для сборки требуется 4 гига свободной рамы, так что делай выводы

Лютое 4.2

Собирал на ноуте и firefox и libreoffice. gentoo, /tmp гигов на 20, 3 гига ОЗУ. А, ну и своп в 4 гига.

Какой-то у вас более другой firefox.

Обычный, из репозитория SuSE 11.4: http://download.opensuse.org/repositories/mozilla/openSUSE_11.4/src/ (от ванильного отличается некоторыми собственными патчами) При пересборке я только указываю: --enable-system-cairo --enable-default-toolkit=cairo-gtk2 --disable-freetype2 --enable-xft

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

У меня с парой десятков вкладок он только ~400 метров памяти ест. А при сборке я уже описал выше - отъедает всё.

Я не знаю, как у вас это получается. Возможно не прибит флэш там, где он не нужен, и скрипты всякие сомнительные дозволены. Сейчас у меня открыто 14 вкладок (больше правда и не бывает наверное), htop показывает общее потребления памяти 426/1978Mb, из которых firefox отъедает (в графе MEM%) 11.2 swаp-раздела нет.

Поможет ли увеличение свопа

Поможет.

~ $ df -h

shm                5.0G            0  5.0G            0% /var/tmp/portage

Когда нужно собрать ff, просто подключаю swap файлом:

~ $ ls / -la | grep swap 


-rw-r--r--   1 root root 3145728000 марта 17 02:56 swapfile

~ $ gcc --version
gcc (Gentoo 4.7.0_pre9999) 4.7.0-pre9999 20120325 (prerelease) commit 319a409ab3eb81240c13c4e7017ef43cf45fa6e9

~ $ firefox -V
Mozilla Firefox 11.0

Найди те у меня в темах, как я ставил pypy, там вся правда про своп...

А, ну мб и баг.

по-моему, ему для сборки требуется 4 гига свободной рамы, так что делай выводы

Я до последнего (с Gentoo слез буквально несколько недель назад) Firefox прекрасно собирал на 3Гб, при чём это был реально работающий десктоп (на котором я без тормозов сёрфился во время сборки) с кучей фоновых сервисов (LAMP, два торрент-демона, всякие nfs/dlna/blah-blah…)

по-моему, ему для сборки требуется 4 гига свободной рамы

Это с какой версии?

У меня 8-ка собирались успешно на 1,5 Гб оперативки.

Возможно, у тебя -O1 в ключах линкера есть. Попробуй убрать его оттуда.

Нормально он собирается на 4х гигах рамы, недавно собирал

Офис как раз без проблем собирается(/tmp 11 гигов).

Очень странно. Я ни разу не видел такого firefox'а. Он у меня что на gentoo, что на дебиане жрёт много. На нетбуке пришлось от него отказаться в пользу хрома, потому как на 512-ти метрах памяти лиса еле шевелится.

Вот make.conf. Ткните кто-нибудь носом, если лишнего чего воткнул. Но кроме firefox'а всё собирается абсолютно без проблем.

# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /etc/make.conf.example for a more detailed example.
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.

# These are the USE flags that were used in addition to what is provided by the
# profile used for building.
USE="a52 aac alsa -arts -avahi -bash-completion bluetooth cairo -consolekit dbus -doc dri -gnome -gtk -hal -icq -ipv6 kde -kdeprefix mmx -mono mp3 -networkmanager nls opengl png qt3support qt4 -semantic-desktop sqlite3 sse sse2 udev unicode X xcomposite"
VIDEO_CARDS="nvidia"
ARCH="amd64"
MARCH="k8"
ACCEPT_KEYWORDS="${ARCH}"

MAKEOPTS="-j2"
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

# 2006/06/07 - Danny van Dyk <kugelfang@gentoo.org>
# Multilib settings for all amd64 subprofiles.
MULTILIB_ABIS="amd64 x86"
DEFAULT_ABI="amd64"
# Do not remove this one, or all kinds of hell breaks loose.
ABI="amd64"

# 64bit specific settings.
CHOST_amd64="x86_64-pc-linux-gnu"
CDEFINE_amd64="__x86_64__"

# 32bit specific settings.
CFLAGS_x86="-m32"
LDFLAGS_x86="-m elf_i386"
ASFLAGS_x86="--32"
CHOST_x86="i686-pc-linux-gnu"
CDEFINE_x86="__i386__"

LINGUAS="ru"
XSESSION="KDE-4"

GENTOO_MIRRORS="http://gentoo.llarian.net/ http://www.las.ic.unicamp.br/pub/gentoo/ http://gentoo.c3sl.ufpr.br/ http://gentoo.inode.at/ "

PORTDIR_OVERLAY="/usr/local/portage"
source /usr/local/portage/layman/make.conf

INPUT_DEVICES="evdev"
#PORTAGE_BINHOST="http://gentoo.wever.org/x86_64/core2/"

PORTAGE_NICENESS=10
PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}"
EMERGE_DEFAULT_OPTS="-vb --jobs=2 --load-average=3 --autounmask=n"
PORTAGE_TMPDIR="/tmp/portage"

Я тоже swap файлом подключаю. Попробую сегодня на ночь воткнуть побольше.

10.0.1-r1 у меня ещё собрался. А вот 10.0.3 уже не хочет.

начиная с gcc 4.7 должно стать получше.

А у меня binutils-2.22. емнип как раз в этой версии прожорливость ld оптимизировали.

Уже было тут: [12309] вот и компиляй современный софт По теме: посмотреть, например, в сторону --no-keep-memory в LDFLAGS. Собирается и на 1,7 ГБ. Своп, конечно, в процессе кушает, но собирается.

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

там память нужна в больших количествах только при паре линковок ld - сваппинг не такой уж интенсивный, раз записал - раз прочитал

Очень странно. Я ни разу не видел такого firefox'а. Он у меня что на gentoo, что на дебиане жрёт много. На нетбуке пришлось от него отказаться в пользу хрома, потому как на 512-ти метрах памяти лиса еле шевелится.

Не знаю, как их там собирают, у меня в SuSE (пересобранный) обычно такая картина: http://www.pictureshack.ru/images/2527Feirfox_mem.png и я не припомню, чтобы когда-то было намного больше.

htop показывает занятыми ~500Mb

ты подожди до момента линковки — ld будет занимать ~1500M

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

Или пиши в багтрекер.

и что там в багтрекере напишут? угадай с одного раза

БЕЗ свопа

в момент вызова линкера твои -jX не имеют смысла (тк работает всё равно ОДИН процесс линкера)

имеет смысл только emerge -j1
кури матчасть

Откуда вы лезете такие умные, а? Работает один процесс линкера, да, а в тот же момент другие процессы make делают своё чёрное дело - компиляют, например. g++ на моём ноуте отжирает при запуске до восьми процентов памяти (от двух гигов), сам make распухает до 20+ процентов. Вот теперь представь себе: ld медленно отжирает память, блок за блоком, свободной оперативки остаётся всё меньше, а тут параллельно с ld постоянно запускаются процессы g++, отжирая свою долю памяти. Свободная память кончается, начинается свопинг и борьба за оперативку: один процесс g++ умирает, ld кушает оперативку, появляется новый g++, отбирает у ld память, заставляя ld лезть в своп.

// выдохнул

а в тот же момент другие процессы make делают своё чёрное дело - компиляют, например.

сначала происходит компиляция, потом линковка скомпиленых объектников в бинарь фф и либу xulrunner-а. кури матчасть дальше

выдохнул

вдохни обратно

да, у меня -j5 умвр

/var/tmp/portage
не в tmpfs,? У меня на 4Гб собрался.

да не знаю, в ебилде прописана проверка на наличие 4-х гигов памяти

по-моему, ему для сборки требуется 4 гига свободной рамы

по-моему это гон.

Не знаю, что там с фуррифоксом, а во время сборки chromium'а одновременно и линкуется, и конпелируется (с -j2) - там несколько бинарников, которые друг от друга не зависят, а потому собираются одновременно.

если собирать при запущеных kde, firefox, etc — то не гон

если собирать при запущеных kde, firefox, etc — то не гон

КДЕ, ФФ запущены, ВНЕЗАПНО!

Не знаю, что там с фуррифоксом

о чём и речь. фф отваливается при линковке libxulrunner, параллельно с которой ничего больше не конпеляется

emerge firefox

free -m
             total       used       free     shared    buffers     cached
Mem:          3961       3757        203          0        176       2034
-/+ buffers/cache:       1546       2414
Swap:         4243          0       4243

Кеды и ФФ запущены.

Mem: 3961

ну ты понел. речь про отвал на 2G вообще всей системной памяти