Форум
Arch системное время
BigOrange:
йогурт все никак мне читалку новостей не соберёт
долго...
А ты makepkg.conf меняешь, или он у тебя по умолчанию? Я вроде тебе давал.
sudo nano /etc/makepkg.confРаскомментируй строку 44 в /etc/makepkg.conf MAKEFLAGS="-j2", и установите значение MAKEFLAGS="-j5" (количество ядер твоего проца +1)
Измени значения строк 40 и 41 на:
CFLAGS="-march=x86-64 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
CXXFLAGS="${CFLAGS}"
redix:
-march=x86-64
-fstack-protector
Имхо, для современного компилятора достаточно указать "-march=native", а ещё лучше подобрать опцию под свой конкретный проц - https://wiki.gentoo.org/wiki/Safe_CFLAGS. Если софт ставится из мусорки-АУР'a, то вместо "-fstack-protector" лучше использовать "-fstack-protector-strong", или даже "-fstack-protector-all" (но в последнем случае могут быть проблемы со сборкой вообще).
redix:
А ты makepkg.conf меняешь, или он у тебя по умолчанию?
чёт я про него забыл совсем
заварить_чайку:
а ещё лучше подобрать опцию под свой конкретный проц - https://wiki.gentoo.org/wiki/Safe_CFLAGS.
а для этого барахла что посоветуете?
~$ grep -m1 -A3 "vendor_id" /proc/cpuinfo
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Celeron(R) CPU 1037U @ 1.80GHzДобавлено позже:
примус, кстати, так и не заработал ((
redix:
С мусоркой не согласен категорически, там находится огромная куча софта, которая присутствует в официальных репах других дистрибутивов.
Признаю, назвав "мусоркой" я несколько перегнул палку. Ваш покорный слуга так же пользуется аналогом арчевского аура в генте - неофициальными оверлеями, в этом смысле рыльце моё в пушку (а что делать? нужного софта зачастую нет в главном дереве). Но такие ебилды в сторонних оверлеях генты , как и пакаджбилды AUR в арче не поддерживаются официальными дистростроителями. Безопасность и надёжность их также лежит на совести ебилд/пакаджбилд-писателя, который запросто может оказаться каким-нибудь васяном. Поэтому дополнительная проверка на потенциально опасные функции (-fstack-protector-strong или *-all) лишней не будет.
posixru:
это благодатная почва для посадки ветвистого холиварчика!
Истинно!)
BigOrange:
а для этого барахла что посоветуете?
Этот проц основан на IvyBridge с некоторыми урезанными функциями. Но для целеронов в gcc нет своего отдельного параметра архитектуры, поэтому принято использовать native (ахтунг! этот способ не подходит при кросскомпиляции!):
-march=nativeПредложенный уважаемым redix'ом
-march=x86-64тоже иммеет право на существование, но только как общий для всех 64-х разрядных процев. Другими словами, такой ключ говорит компиятору "собери софт под 64-хразрядную платформу, а не под 32 или, скажем, arm". Но если есть возможность повлиять на процесс сборки и дать ему команду собрать приложение под МОЙ конкретный процессор, то почему бы этой возможностью не воспользоваться? Понятно, что сейчас время и железо уже другие и флаги компиляции не так сильно влияют на результат, как в начале двухтысячных, однако зачем лишать себя хоть и маленьких, но всё же вкусных плюшек?:))
Также в обозначенном проце нет поддержки AES, поэтому убираем лишний код из собираемых приложений:
-mno-aesУменьшаем вес софта и скорость его выполнения (минус - время компиляции увеличивается):
-O2Предыдущий ключ можно поменять на -О3: скорость приложения ещё более повысится и ещё более уменьшится его вес, но нет гарантий, что сборка будет успешной. Можно использовать ключ -Os: это по-максимуму уменьшит размер приложения, что хорошо при малом объёме кеша CPU и оперативки.
Во время компиляции создаются куча промежуточных файлов, которые пишутся на диск и потом удаляются. Это - лишнее время сборки, плюс износ харда. Следующий ключ позволяет по возможности избавится от этого:
-pipeРезюмируя, привожу опции, которые будут безопасны и полезны для
BigOrange:
Intel(R) Celeron(R) CPU 1037U @ 1.80GHz
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong -mno-aes"Вообще, разных ключей, как полезных, так и нет, очень много. Можно углубиться в техническую документацию процессора и улучшить оптимизацию. Однако, чтобы не попасть впросак, на всякий случай лучше избегать излишеств в опициях компилятора.
Добавлено позже:
redix:
лично я не вижу ничего плохого в том, что нужная софтина будет спокойно собрана из сорцев.
Скажу больше: если прогу можно собрать из исходников, то лучше её собрать самому, чем юзать собранную каким-то дядей. Ведь только в этом случае можно повлиять на эту прогу, на то, с какими возможностями она будет скомпилирована. Поэтому и использую сурс-бейсед линукс :))
Для себя любимого я так и делаю, частично, но есть ведь ещё и другие, которым иногда бывает нужно то что мне даже теоретически ненужно, так что... Вполне беззастенчиво и не ощущая приступов паранойи пользую собранное другими, как официальными так и не очень. Ничего плохого никогда не случалось, так зачем мучить седалищные мышцы? Не люблю когда бесполезную работу, жутко! :)))заварить_чайку:
если прогу можно собрать из исходников, то лучше её собрать самому, чем юзать собранную каким-то дядей
О, новость в тему: В AUR-репозитории Arch Linux найдено вредоносное ПО, судя по количеству коментов, альтовцам есть дело до всего на свете.