Teljes rendszer újrafordítása

Gentoo

Üdv!

A napokban jöttem rá, hogy a make.conf-ban helytelenül adtam meg az architektúrát (Pentium-M volt Pentium4 helyett, Celeron-M procim van).

Hogyan lehet a teljes rendszert maradéktalanul újrafordítani?
Az "emerge -e world" ugyan újratelepíti a csomagokat, de nem fordítja őket újra.

Előre is köszönet!

  • 5880 megtekintés

( turul16 v | 2008. 02. 10., v – 12:38 )

Miert nem forditja ujra ?
Talan elsodlegesen leforditott binaris csomagokat tesz fel ? Ha igen akkor tiltsd le oket, vagy torold le oket.

Valahogy így néz ki a kimenet minden csomagnál:

>>> Emerging (1 of 656) sys-apps/portage-2.1.3.19 to /
* portage-2.1.3.16.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* portage-2.1.3.19.patch.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
* checking portage-2.1.3.16.tar.bz2 ;-) ... [ ok ]
* checking portage-2.1.3.19.patch.bz2 ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking portage-2.1.3.16.tar.bz2 to /var/tmp/portage/sys-apps/portage-2.1.3.19/work
>>> Unpacking portage-2.1.3.19.patch.bz2 to /var/tmp/portage/sys-apps/portage-2.1.3.19/work
* Applying portage-2.1.3.19.patch ... [ ok ]
* Setting portage.VERSION to 2.1.3.19 ... [ ok ]
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/sys-apps/portage-2.1.3.19/work/portage-2.1.3.16 ...
>>> Source compiled.
>>> Test phase [not enabled]: sys-apps/portage-2.1.3.19

>>> Install portage-2.1.3.19 into /var/tmp/portage/sys-apps/portage-2.1.3.19/image/ category sys-apps
patching file make.conf
>>> Completed installing portage-2.1.3.19 into /var/tmp/portage/sys-apps/portage-2.1.3.19/image/

ecompressdir: bzip2 -9 usr/share/man
strip: i686-pc-linux-gnu-strip --strip-unneeded -R .comment
usr/lib/portage/bin/tbz2tool
* checking 159 files for package collisions
>>> Merging sys-apps/portage-2.1.3.19 to /
--- /etc/
>>> /etc/make.conf.example
>>> /etc/make.globals
--- /etc/portage/
>>> /etc/portage/.keep_sys-apps_portage-0
... stb. ...

Ha nem tévedek a Pentium-M Centrino inkább a P3-hoz áll közel.
(amúgy a linkben, amit adtál ott is van, h gcc3-nál még "-march=pentium3"-at kell beállítani, nem "pentium-m"-et)

A Mobile Pentium 4-M-re pedig "pentium4" beállítást javasol.
Viszont kicsit homályos a dolog, ott Northwood magot említ.

Ez pedig egy Celeron M 420, Yonah maggal.
Kissé magam is bizonytalan vagyok a besorolással.

http://gentoo-wiki.com/Safe_Cflags#Intel_Core_Solo.2FDuo.2C_Pentium_Dua…

nekem ugyanolyan procim van, és a -march=prescott lesz a te barátod (lásd a linken a 2. megjegyzést)

---------
"Ha igazat mondasz azt végig unják, ha feldíszíted azt jól meg dugják"
szerény blogom -- új címen!

Vess egy pillantást erre: Cflags for Pentium M(Centrino)/Celeron M
Csak akkor forgass prescott-tal, ha Core Solo alapú Celeron M-med van!

Remélem megkíméltelek egy felesleges újraforgatástól.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( kulik | 2010. 01. 04., h – 13:00 )

emerge --emptytree

eltart egy darabig :D

( balintdavid | 2010. 01. 04., h – 13:24 )

Megkérdezhetem, hogy manapság kb mennyi időbe telik ilyesmi?

Mert anno amikor a Pentium Promra kernelt forgattam, éjszaka járni kellett hagynom a gépet, pedig az még a sovány 2.4-es kernel volt.
----------------------------
Debian Lenny + LXDE

E6850-en 4GB RAM-mal a kb 750 csomag (kd4 + rendszer) ha jól emlékszem olyan 18-22 óra körül van. Ugyanez i7 860 + 8GB RAM-mal kb 8-10 óra. De estére pontos adatot is tudok mondani, mert reggel 9-kor indítottam egy teljes újraforgatást. Igaz ez csak P4-re lesz, ezért valamivel gyorsabban végez, mintha minden optimalizációt használna a fordító.

egyszer csináltam életembe egy ilyen --emptytree dolgot

nagyságrendben olyan 500 package lesz, ha jól emléxem.

namost, lassú. nagyon, egy 1700-as cerkán nekem 4-5 napig ment.

a legjobb, ha beveted a distcc-t. arra jó, hogy több gépen fordítson egyszerre. wanon keresztül is repeszt, csak be kell kapcsolni, hogy tömörítsen.
érdemes utánna nézni, mondjuk kell legalább egy másik gép hozzá, és szerintem gentoo legyen rajta, én más distroval nem tudtam összehozni.

ha több magod van, vagy több gépen indítod el, célszerű a --jobs-al több szállon indítani, mert az autoconf csak 1 szálon tud menni, ilyenkor a -j -t is úgy állítsd (szóljatok ha tévedek)

szerintem jobb több jobs-al és -j1 -el indítani, mert egy csomó package felülírja a -j beállításodat, és 1-re állítja.

szoktak ccache-t használni, én sose használtam. elvileg második fordításra gyorsít csak.

írnak még --keep-going kapcsolót is, mert ugye az 500 package-ből bele fogsz bug-ba futni, és meg fog állni a fordításod valahol.

először a gcc-t forgasd meg, és optimalizáld, talán egy lélegzettel gyorsabb lesz a dolog
érdemes a gcc flag-jeit is megnézni.

mégvalami: kb ennyit még sose járattad a cpu-t, nézd, le ne sűljön :D

( Ewkins | 2010. 01. 05., k – 00:31 )

Celeron M 420-nak semmi köze a Pentium M-hez (Banias és Dothan mag), sokkal inkább a Core Solo, Core Duo, Pentium D processzorokhoz (Yonah mag), éppen ezért a -march=prescott a nyerő.

Mármint ha megéri újrafordítani a teljes rendszert a nagy büdös semmiért hippi Gentoo-s. Haha.. :P xD

Jaja. http://en.gentoo-wiki.com/wiki/Safe_CFLAGS

GCC 4.2 introduces a new -march option, -march=native, which automatically detects the features your CPU supports and sets the options appropriately. If you have an Intel or AMD CPU and are using >=sys-devel/gcc-4.2.3, using -march=native is recommended. Do not use -march=native if you use distcc on nodes with different architectures as this may produce unusable code.

jAzz

( zui84 | 2010. 02. 06., szo – 21:40 )

Hali,

miert kellene ujraforditani barmit is emiatt?

Ez a valtozo csak a forditonak atadott parameterekre vonatkozik.

Ha helyesen allitod be akkor tobb dolgot tud hasznalni a processzorod kepessegeibol -> a fordito gyorsabban fog forditani. Illetve vannak olyanok amik az optimalizaciora vonatkoznak. De annak sincs koze ahhoz hogy -march vagy egyeb parameterkent mit adsz meg.

Felesleges emiatt tekerni a procid. Nem lesz tole se jobb se rosszab semmi. A kesobbiekben jobb lesz a forditodnak/procidnak hogyha optimalis forditasi beallitasokat hasznalsz. De mas haszna ennek nincs.

Azok a mondasok, hogy a gentoo azert jo, mert optimalizalva tudsz a te gepedre szabva progikat tobb dologbol is tevodik ossze.
- use flagek-> csak azok a feature-ok kerulnek forditasra amiket hasznalsz. Ezzel tudsz gyorsitani programok indulasan, mert igy kevesebb dolgot kell esetleg (alkalmankent feleslegesen) betoltenie az indulo programodnak.
- forditasi optimalizalas. Tipikusan -O g++ parameter. Ezzel mondod meg hogy milyen szintu legyen a fordito optimalizasa. Irok erre egy egyszeru peldat.

A program(reszletem) csinalja azt, hogy kiszamolja mondjuk 5!-t.
Ha nem hasznalsz optimializast, akkor elkeszul az assembly, majd gepi kod, ami ezt kiszamolja, amikor fut a programod.
Ha hasznalsz, akkor a fordito kiszamolja (mivel ez egy statikus ertek), es a progrtamod gepi kodja csak annyit fog tartalmazni, hogy kiirja azt, hogy 120.
Igy a futas gyorsabb, mivel a procid nem szamol, de a forditas lasabb, mivel forditasi idoben zajlik a szamolas.

Persze ez nem ennyire egyszeru, de kb ez az ertelme a -O valtozonak, meg annak, hogy gyorsabban fognak indulni a progijaid... De tipikusan ezzel nem lehet tul sok idot nyerni... Cserebe lassabb lesz a forditasod...

zui