[netbook][gentoo]Сборка на другой машине

>Можно ли безпроблемно собрать в chroot

можно

если на хостовой машине проц от интел, вообще проблем не будет

Да, там Корвет с E8400 на борту.

distcc и не ставить его клиент на ноутбук - все будет компелять «большой» комп

Внезапно спасибо, раньше как то недодумывался. Только распаковка, configure все равно ведь на нетбуке будет производиться. Chroot по моему удобнее.

будь я исправлен Сильвией, если ошибаюсь, но вроде как атом и коре 2 архитектурно почти идентичны, можно даже CFLAGS не менять

ну разве что -funrool-loops не юзать и кеши прописать. Поддержка SSSE3 имеется в атоме.

Реквестирую CFLAGS атомных гентушников.

Но зато все сразу попадает на нетбук, не нужно будет извращаться с копированием.

Представь: поставил ты из chroot,

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

Я не собирался хард прицеплять. Затаренный stage4 скинется на флешку и распакуется с помощью SystemRescueCD. А насчет новых прог я постараюсь все нужное поставить сразу. Да и если что то сильно понадобится поставить - на нем уже установленна UNR 10.04 из которой собственно и пишу.

Новые программы можно ставить из бинарных пакетов, которые можно собирать в том же chroot

>но вроде как атом и коре 2 архитектурно почти идентичны

в каком месте? атом in-order идет, в отличие от приличных cpu.
так что ставить свежий gcc c march=atom

>так что ставить свежий gcc c march=atom

Уже собираю там gcc-4.5.1-r1 пока с -march=core. Соберется поменяю на -march=atom.

march=native тогда сделай и не парься.

покусаю, абсолютно разные процессоры, общий только набор инструкций , и то не полностью

*стыдливо забился в уголок

самый неудачный вариант при сборке для другого компа использовать -march=native



я бы ставила

-O2 -march=atom -mssse3 ( -fomit-frame-pointer ) -mfpmath=sse

для GCC 4.5.1+

для более старых:

-O2 -march=core2 -mtune=pentium -mssse3 -mfpmath=sse ( -fomit-frame-pointer )

собрать из чрута на большом компе и потом затарить и распаковать на нетбуке. GCC предполагаю 4.5.x Можно ли безпроблемно собрать в chroot

да, без проблем.

там где нет -march=atom
можно использовать -march=core2 -mtune=pentium

именно так :) получится in-order

А поставить Calculate на нетбук-это не выход?

>istcc не предлагать ибо в таком случае всю основную работу все равно проделывает нетбук.

это не совсем верно, наиболее процессороемкий этап - перевод обработанного препроцессором исходника в asm , это делается на удаленной машине, хотя зависит от того, что собирается.


вообще рекомендации по сборке в чруте для другого компа будут такие

1) выставить флаги для целевой машины, но так, чтобы собранное работало на той машине на которой собираете,

т.е. если бы вы собирали на AMD, то пришлось бы не использовать -mssse3 , а только -msse3 , -mmovbe возможно использовать на Атом и Нехалем или Вестмере, но нельзя на Коре2 Конро или Пенрин

2) если особенностей архитектуры много, то желательно задавать флаг -mtune=цель

для атома можно использовать значения atom или pentium ( первый пентиум имел in-order)


3) ни в коем случае не использовать -march=native , тем не менее очень желательно задать размеры кешей целевой системы, для систем с маленькими кешами часто используют -Os , это не совсем хороший вариант если вам известны кеши на целевой системе, лучше задавать -O2 --param l1-cache-size=РАЗМЕР_В_КБ --param cache-line-size=64 --param l2-cache-size=РАЗМЕР_В_КБ

Я в принципе тоже самое и поставил

CFLAGS="-g0 -march=atom -O2 -mfpmath=sse -mssse3 -ftree-vectorize -pipe"

Сейчас при смене march с core2 на Atom выпало

configure: error: C compiler cannot create executables
See `config.log' for more details.
 * ERROR: sys-devel/binutils-2.20.1-r1 failed:

К чему бы это?

>-ftree-vectorize

бяка

с этим флагом постоянно какие-то проблемы огребал

GCC 4.4 ?

-ftree-vectorize я бы все же с осторожностью использовала, тем более на атоме, хотя icc например активно использует векторизацию в SSE3 с -xL


-fomit-frame-pointer ? отладка нужна или нет ? если не нужна - то лучше ставить этот флаг, + 1 регистр

это не совсем верно, наиболее процессороемкий этап - перевод обработанного препроцессором исходника в asm , это делается на удаленной машине, хотя зависит от того, что собирается.

Не знаю, я как то давно пробовал там на большой комп отправлялись задания, он их за секунд 30 собирал, отправлял результату клиенту и опять простаивал. Наверно как тут сказали уже маленькую машину не надо прописывать как клиент.

GCC 4.4 ?

на ББ 4.4.5, на атоме собрал уже 4.5.1-r1 и как писал выше он не хочет собирать под атом

-ftree-vectorize

бяка

с этим флагом постоянно какие-то проблемы огребал

Вся система собрана с ним- УМВР. Ах да, ты же KDE юзаешь, наверно там проблемы и огребал..

>Тобишь собрать из чрута на большом компе и потом затарить и распаковать на нетбуке

Всё даже проще и удобнее. Делаешь chroot-копию системы на сабноуте и собираешь там пакеты по emerge -b

Копируешь бинарные пакеты на сабноут и делаешь там emerge -K

Я так ставил Gentoo на Toshiba Libretto 50ct (P75, 32RAM, 850M HDD). На целевой машинке ни GCC не надо, ни distcc :)

>-fomit-frame-pointer

amd64 же, там ведь он по умолчанию, или нет?

>Ах да, ты же KDE юзаешь, наверно там проблемы и огребал

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

> Если тебе нужно поставить новую программу, опять хард будешь к компу прицеплять?

Новую программу можно емержнуть прямо на ноуте. Не так страшен чёрт, как его малюют ;)

MAKEOPTS=-jN

N для distcc надо выставлять побольше, чтобы прогружать удаленную машину , для Core2Duo это примерно -j16, ну и возможности сети учитывайте, через вай фай core2 не нагрузить на полную
еще в целях distcc не нужно использовать сам нетбук как компилирующую машину, пусть только работает препроцессор. ассемблер, компоновщик и всякие libtool и прочее.

например openlibreoffice :) который кстати и с distcc собирать неудобно тоже

про архитектуру надо было сразу

-O2 -march=atom -mssse3 -msahf -mcx16


--param l1-cache-size= ( 24 ?)
--param l1-cache-line-size= (64 ?)
--param l2-cache-size= (512?)

>Вся система собрана с ним- УМВР.

потому что 64, на i?86 баги в GCC не особенно пытаются исправлять (

l2 - 512kb

l1 cache size в спеках 24.

Вот про l1-cache-line-size я не знаю что поставить

configure: error: C compiler cannot create executables
See `config.log' for more details.
 * ERROR: sys-devel/binutils-2.20.1-r1 failed:

Я мудак. gcc то не переключил :)

>Я мудак

полностью согласен -))

l1-cache-line-size
собрать хелло ворльд какой-нибудь с gcc -v и посмотреть,
скорее всего 64 там

gcc -v -march=native

touch /tmp/null.c; gcc -c -march=native -v /tmp/null.c 2>&1 | grep march | egrep --color — '\s-m\S+|--param \S+'

Опять на ЛОРе пахнет жиром,

Повсюду жировые сталагмиты,

Это все предвестники Фрактала,

Самого жырного троля!

Вобщем с -march=atom куча глюков при сборке из chroot.

xulrunner не собирается и еще кое что. Ругается на Illegal instruction. Соберу с 4.4.5 под core2.

какой процессор на машине на которой собираете?

надо полагать - core2

E8400

-mnomovbe тогда в флаги на хосте сборки
ну или как вариант

-march=core2 -mtune=atom

тогда точно все нормально соберется

Раз такое дело,я предлагаю не заморачиваться с оптимизацией под atom.
Только время потеряете

других нелегальных инструкций на атоме по сравнению с penryn не должно быть

ну и для информации:
(а вот native на пенрине включит sse4.1 , которого на атоме нету :) )

У атома как оказалось тоже есть инструкции которых нет в коре2.
Из-за этого и возникла проблема.

Интересно сколько времени будет пересобираться мирок из ~300 пакетов на Атоме?:)

>Реквестирую CFLAGS атомных гентушников.
CFLAGS="-O2 -march=atom -fno-align-functions -fno-align-labels --param l2-cache-size=128 -fomit-frame-pointer -pipe"
можешь смело добавить -mfpmath=sse -mssse3

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