collect2: ld terminated with signal 9 [Killed]

dmesg | grep -i oom

dmesg | grep -i oom knotify4 invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 [<ffffffff81086155>] oom_kill_process.clone.10+0x40/0x23a [<ffffffff810860d8>] ? oom_badness+0xce/0x10b [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name

Вывод: ld был прибит OOM-killer'ом из-за недостатка памяти.

А сделать с этим что можно? Вставить только еще оперативы чтоли? Неужели какойто браузер при компиляции требует столько оперативы

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

Можно ещё увеличить swap.
Да, Firefox треубет много ресурсов для компиляции.

А swap не цепляется?

я про всю виртуальную память. Свап конечно поможет, но скорость компиляции от этого не прибавится

Память 1 Гб swapon -s Filename Type Size Used Priority /dev/sda6 partition 1052220 446036 -1

Неужели какойто браузер при компиляции требует столько оперативы

а почему бы ему и не потребовать столько оперативы?

сделай 2Гб и запусти снова ) еще вроде как опция GCC -pipe память жрет, можно ее убрать, если она есть

Перераспределять место на диске чето не хочется увеличивая свап. Вот про опцию GCC -pipe можно поподробней как отключить.

swapon -s Filename Type Size Used Priority /dev/sda6 partition 1052220 802260 -1

Да и вроде судя по этому свап то полностью не используется. А так уже все висит скоро выдаст туже ошибку. И может имеет смысл убить иксы и кеды на время и пробывать пересобирать они же тоже жрут не мало оперативки

что мешает сделать временный своп в файле?

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

А почему не имеет?

Поподробней как это сделать.

Сейчас попробуем

dd if=/dev/zero of=/<path_to_swap_file>/myswap.sw bs=1M count=2000
mkswap /<path_to_swap_file>/myswap.sw
swapon /<path_to_swap_file>/myswap.sw

Создастся swap файл размером 2000 мегабайт.

обычно монтирую тмпфс и там все собираю, но сегодня фокс не собрался с сообщением типо «свободного места в разделе меньше 8Г»

мысленно послав его на ... я подумал о -бин

когда-то так было с опеноффисом и ко.
«а может ну его и ...»
короче не крттичный для сборки из сырцов пакет

Установилось в голой консоли. Проблема решена. Не когда не думал что на компиляцию Firefox надо столько памяти

это фигня, вот недавно новость пробегала, что при сборке Firefox под виндой линкер падает, выжирая все 3 гига доступной для 32битного процесса памяти :)

Вот про опцию GCC -pipe можно поподробней как отключить.

в /etc/make.conf должна быть, если есть

про нее в гентушном хэндбуке говорится где-то

я за firefox-bin
один фиг, зато систему не насилует
(я тут в dmesg случайно заглянул - такой жжести там я ешшо не видел)

был бы браузер-конструктор ... я б вместо закладок ссылок на линкс и пр. поставил в зависимости от контентов...

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

А у меня история успеха.

Обновлённый Firefox 9.0.1 сегодня неожиданно откомпилировался системным Clang'ом v.3.0 в FreeBSD 9.0-PRERELEASE. Компиляция предыдущей, 8-я версии, вываливалась с ошибкой — приходилось делать исключение, для компиляции Fx в GCC 4.2.2 условными операторами в /etc/make.conf.

Переходите на LLVM/Clang v.3.0.

это конечно + для LLVM/Clang
но тяну таки одеяло в свою сторону: зачем?
браузер это не то место в системе которое стоит компилить руками (ну, по крайней мере костяк)
пруфита ноль

месье любит двое суток гном собирать или в чём причина использования генты на данной машине? :) рекомендую распределенную компиляцию или хотя бы SSD под систему и swap.

а ты настоящий iZEN? :)

на компиляцию FF в некоторых случаях до 3Гб надо. на libreoffice и того больше.

Увидел свою аватарку, подумал что я вопрос запостил и не помню. А самое главное проблем со сборкой FF никогда не было. Потом таки поглядел на ник и успокоился - пока я с ума ещё не сошёл.

пруфита ноль

Скорость компиляции у Clang заметно больше, чем у GCC, и качество диагностических сообщений во время компиляции лучше.

Например, GCC у меня собирает рабочее окружние (домашний десктоп на основе Xfce и приложений GNOME) за 4,5 часа, а LLVM/Clang требуется всего 2,5-3 часа — что называется «почувствуйте разницу».

пруфита ноль

это как раз из того, где профит есть и собирать с оптимизацией нужно
а всю системную хрень можно собирать с -Os

Нравится генту. А двое суток и не потребуется собирать гном

libreoffice собирал на этом компе старых версий. Ну сейчас уже перешел на бинарную версию. Просто собирать его не вижу смысла так как пользуюсь им только график работы посмотреть если забыл вдруг когда на работу

А сделать с этим что можно?

emerge firefox-bin

Кстати, воткнуть 64-битную ОС менее чем на 4Gb RAM — начинание, достойное всяческого порицания.

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

по моему, Вы, как и многие другие люди, ещё не знаете, что такое мультилиб и что вайн нормально работает и с 64 и с 32 (даже есть папка syswow64) софтом на 64-битной системе. В дебиане (и его потомках) и генте (вероятно, и в RHEL-производных, но тут не могу гарантировать) мультилиб работает автоматически, пользователю даже знать об этом не нужно. Тогда как деградация производительности при использовании бинарного дистрибутива, где все проги скомпилены на i686, будет сильной в сравнении с 64-веткой того же дистриба. Единственное, иногда могут возникнуть проблемы с ассемблер-специфичным софтом, типа gens, что он не хочет компиляться (для работы с мультилиб, всё-же нужна некоторая поддержка в ./configure со стороны ментейнера). Это решается подключением оверлея, где уже всё профиксили, либо гуглением и нахождением нужного ./configure (иногда ещё и патча), либо chroot в 32-битную версию. Но, могу сказать сразу, что подобные проблемы возникают только при компиляции редкоиспользуемых сообществом пакетов (читай «у гентушников», но тут можно подрубить оверлеи), которые мейнтейнерам просто лень патчить. Если Вы используете бинарный дистрибутив, то у Вас не возникнет никаких проблем.

Единственная реальная проблема 64-бит: кушает чуть больше памяти. но выигрыш в производительности полностью это нивилирует, особенно, если SSD есть под своп или оперативы от гига и более.

по моему, Вы, как и многие другие люди, ещё не знаете

По-моему, ты дожил до 2012 года, а так и не знаешь, что sizeof(void*) на 64 битах аж в два раза больше, чем на 32. Потребление памяти на 64 нативных битах ощутимо больше. Ситуация, когда оп ставит 64 бита на 1 гиг, напоминает анекдот про больного, щемящего себе яйца дверью.

Хм, а я думал, зачем мне 4 гига оперативы на ноутбуке. Всё таки хорошо, что взял. Проблем при компиляции, подобных данным, нет. Иногда просто чистить место ддля компиляции либреоффиса, и всё.

А почему бы хомяк и /usr/portage(или /var/tmp/portage) на раздел, где много места, не перекинуть?

Ну, с твоей аватаркой только двое, вот антигуглоплюсники это вообще жесть, штук 8 их что ли.

месье любит двое суток гном собирать

Гном быстро собирается. Двое суток его нужно собирать на чём-то типа первопня с сотней мегов оперативы.

это я образно сказал, ессно. Но, ИМХО, на таком говне, как у ОПа, генте без дистцц нет пути.

и насколько реально выше? :)

Не пиздите. Лично собирал gentoo на машине с 1G RAM (firefox тогда был, правда, не 9-й). Всё отлично собиралось (включая openoffice и kde4) и летало.

Да, amd64, конечно.

спов включали, сколько мб он был? явно видно, что у ТС нету свопа с должным размером, поэтому и возникли проблемы.

спов включали, сколько мб он был? явно видно, что у ТС нету свопа с должным размером, поэтому и возникли проблемы.

И сколько же должен быть этот должный размер?

откуда я знаю? могу сказать точно, что для либреофиса итого с оперативой не меньше 4гб (ну теоретически можно около 3,4 , но лучше с запасом, т.к. ещё Xorg и все дела) при условии отсутвия всяких хуюнити и прочих файерфоксов, говорые сразу полтора гига отожрут.

это как раз из того, где профит есть

т.е., LLVM собирает фф лучше?

Да гига почти всегда хватает. Тут как я потом выяснил не собиралось потому что вся память ушла на иксы, кеды, nginx, MySQL, ejabberd. А как остановил только иксы все сразу прошло норм.