emerge wine - вешает систему
kiev1 8 января, 2007 - 12:34
при компиляции все тормозится пока не виснет окончательно - что делать? (памяти гиг)
на другой машине тоже только с каким-то другим пакетом из кде
»
- Для комментирования войдите или зарегистрируйтесь
Было такое
Было такое когда-то. Просто подожди минут десять. Или своп увеличь:)
.
специально на ночь оставлял - не помогает - виснет мертво, на чем уже не помню, надо еще раз попробовать.
А на чём
А на чём виснет?
Последение строки.
emerge --info
поставил MAKEOPTS="-j1"
тоже самое - виснет примерно на этом месте
make[2]: Entering directory `/var/tmp/portage/app-emulation/wine-0.9.29/work/wine-0.9.29/dlls/oleaut32/tests'
x86_64-pc-linux-gnu-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -march=athlon64 -O3 -pipe -mno-3dnow -mno-sse3 -mno-sse2 -o olefont.o olefont.c
и вообще при компиляции часто мышка прилипает к экрану - что делать?
Остановить как
Остановить как можно больше сервисов, выгрузить из памяти всё что можно, увеличить swap...
...
swap почти 5 гигабайт, на винте места больше ста свободного, сервисы не мешают..
вот на этих строчках
x86_64-pc-linux-gnu-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -march=athlon64 -O3 -pipe -mno-3dnow -mno-sse3 -mno-sse2 -o vartest.o vartest.c
gcc сначала съедает первый процессор потом второй, потом память, потом почти гиг свопа и... вот
запустил второй раз - на том-же самом месте, только есть начало с другого процессора потом съело всю память но своп не успело сожрать, только несколько мег и повесило мышку, даже на SysRq не реагировало, (комп естественно не разогнанный - не люблю издеваться над железом).
попробуйте
попробуйте стандартную процедуру: проверить память, понизить частоту процессора/памяти ...
А не разогнана
А не разогнана ли машина?
Попробуй в соседней консоли запустиьт top или htop и смотреть, не жалает ли он вдруг посвопиться (хотя с гигом оперативки это было бы странно).
А проц какой? У
А проц какой? У меня на amd64 тоже виснит наглухо. Единственное, на что грешу - флаги оптимизации и gcc4. Переставлю gcc (без него qemu не собирается) и попробую снова wine скомпилировать.
P.S. Внимательно вглядываясь в сообщения на экране, пришел к выводу, что виснет при компиляции тестов ole32. Никто не знает, нафига эта либа нужна?
_________________
Fedora? rpm -Uhv emerge
ole - технология
ole - технология взаимодействия программ когда в один файл (например документ M$ ворда) вставляется формат другой программы (формулы, картинки). Почти как COM или ActiveX только старше. Короче, к сожалению, нужная вещь.
В make.conf есть опция PORTAGE_NICENESS с помощью которой можно понизить приоритет портажей и гсс. Хотя не факт что поможет..
.
да и на AMD64 и на простой - часто находится что-то что компилируется, съедает постепенно все ресурсы и вешает систему, неужели нет какого-то предохранителя, что-ли?
А своп раздел
А своп раздел создан?
К сожлению нет!
К сожлению нет! Дело в том, что ядро предполагает, что все процессы важны (в соответствии с nice) и поэтому убивать их надо аккуратно, если Вы считает иначе, сообщите об этом ядру.
Проблемы с большим выделением памяти можно решить или увеличением памяти, или увеличением свопа, или уменьшением запущенных процессов, или поставив j1 в make.conf ...
Пробовал
Пробовал закомментировать строку MAKEOPTS в make.conf, но все равно вешается...
_________________
Fedora? rpm -Uhv emerge
А.. собственно,
А.. собственно, уточните версию wine плз.
+1. Версия 0.9.28
+1. Версия 0.9.28 нормально собирается. Да и вообще всё что выще 0.9.20 точно нормально собирается.
у меня вообще
у меня вообще начиная с 0.9.8 все нормально собрались
какой gcc?
У меня четвёртый отжирал полтора гига и прибивался из-за нехватки памяти. В последние минуты жизни выглядело как висяк.
Поэтому уже которую версию вайна собираю третьим.
Если у тебя gcc четвёртый, попробуй собрать третьим (gcc-config --help)
Поставил gcc3.
Поставил gcc3. Все скомпилировалось.
_________________
Fedora? rpm -Uhv emerge
У меня тоже
У меня тоже были проблемы с компиляцией wine с gcc4, хавало всю оперативку и падало со словами cant allocate memory(че то типа этого), а у меня 1Gb RAM + 0.5Gb SWAP, решились сменой флагов оптимизации на менее жесткие( -O2 вместо -O3 )
у меня тоже
у меня тоже висло. я вырубил иксы и поставил на ночь компилиться вроде собрался.
Re: У меня тоже
Несколько версий вайна назад (когда впервые столкнулся с этим, перейдя на gcc4) первым делом поставил о2 - увы, не помогло.
.
интересно что на амд64 когда что-то компилится - то мышка прилипает к экрану иногда - естественно все в ядре есть - preempt и тд
а на семпроне 32 бит - нормально
что делать?
Столкнулся с
Столкнулся с похожей проблемой. Отжирает память своп и отрубается. Бывает тянет с собой еще несколько программ.
Вчера приделал своп в 10Гиг... Долго собиралось. Дело было поздно... не дождался вырубил и пошел спать. На момент остановки сожрало 2,5Гига свопа и 1Гиг оперативки.
Флаг -O3. gcc 4.1
Флаги и gcc попробую не менять. Победить это дело терпением. :)
c аналогичной
c аналогичной проблемой сталкнулся. отжирает свопа на 1Г и типа висла. но она не висит.... нужно подождать и все откомпилиться. на ночь ставлю и все. а проблема эта компилятора из-за понтовых флагов компилятора. вот что было:
-march=athlon-xp -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -fprefetch-loop-arrays :)
а вот недавно все установил предельно просто:
-march=athlon-xp -O2 -fomit-frame-pointer
и вайн спокойно и быстро откомпилися....
А что делает
-fomit-frame-pointer?
Вернее нафига оно нужно? Разве бывают траблы?
все
wine-0.9.30 уже не вешает, собирается очень быстро, не знаю почему...