Vi va di parlare di apt-build?

[Dcromato]

L'ho usato qualche volta e tempo fa ma a quanto pare era troppo presto, non tanto per il grado di maturità del prodotto, ma credo piu al fatto che Debian/Ubuntu non lo digerissero piu di tanto.Ora sto provando a ricompilare qualcosina e sembra anche andar bene (nautilus sembra aver guadagnato).Comunque:questo è il mio apt-build.conf

build-dir = /var/cache/apt-build/build
repository-dir = /var/cache/apt-build/repository
Olevel = -O3
mtune = -mtune=nocona
options = " "
make_options = "-j3 "

che consigli mi date per migliorarlo?

[Gimli[2BV!2B]]

Il -O3 è sconsigliato per compilatori gcc 4.x perché allunga sensibilmente i tempi di compilazione producendo eseguibili più grandi e raramente più efficienti.

Ti consiglierei march al posto di mtune:

• mtune (not --mtune): Tune to CPU-TYPE everything applicable about the generated code, except for the ABI and the set of available instructions.
• march: Generate instructions for the machine type CPU-TYPE. Specifying -march=CPU-TYPE implies -mtune=CPU-TYPE.

Puoi provare questo script, a me ha dato una dritta sensata da aggiungere al march/mtune.

Almeno un anno fa provai a dare una compilata a Iceweasel, ma non gradii il modo in cui veniva trattato il repository dei pacchetti compilati.
Mi hai fatto venir voglia di riprovare...

[Dcromato]

grazie
Dici che è meglio -O2 ?
oppure -Os che una volta consilgiavano su Gentoo per binari piu piccoli?

comunque lo uso per ricompilare applicazioni che uso di piu come Firefox e Evolution.

[Gimli[2BV!2B]]

L'O3 l'ho usato per un po' nella mia Gentoo, i tempi di compilazione erano più lunghi e non ho notato grandi miglioramenti quando ha raggiunto ogni pacchetto del sistema, ma non ho fatto prove scientifiche perché avrebbero richiesto un po' troppo tempo (emerge -e world su un Athlon XP richiede circa 3 giorni con un sistema Kde completo).

L'Os non te lo consiglio perché il tuo nocona ha una buona cache; può rivelarsi più performante con cpu con la cache molto piccola.
Per esempio il kernel compilato con Os sul mio Via Esther (cache size: 128 KB) risulta più veloce al boot di qualche secondo; già l'Athlon (cache size: 256 KB) con Os ha tempi di boot di meno di un secondo più veloce.

In ogni caso ho provato questo:
root@altarf:~# apt-build --remove-builddep --noupdate install xulrunner-1.9 iceweasel

Con questo apt-build.conf:

build-dir = /var/cache/apt-build/build
repository-dir = /var/cache/apt-build/repository
mtune = -mtune=pentium-m
Olevel = -O2
options = " -march=pentium-m -mfpmath=sse"
make_options = " -j2"

Però durante il configure succede questo:

creating cache ./config.cache
checking host system type... i486-pc-linux-gnu
checking target system type... i486-pc-linux-gnu
checking build system type... i486-pc-linux-gnu

Poi, durante la compilazione, viene usato -Os e basta. C'è qualche cosa che non mi torna.

Non serve nemmeno impostare le varie variabili di compilazione:

CHOST="i686-pc-linux-gnu"; export CHOST
CFLAGS="-march=pentium-m -O2 -mfpmath=sse -pipe -fomit-frame-pointer"; export CFLAGS
CXXFLAGS="-march=pentium-m -O2 -mfpmath=sse -pipe -fomit-frame-pointer"; export CXXFLAGS

Mi son perso qualcosa?

[Dcromato]

guarda ne so meno di te...ora sono a lavoro con un C7m e il tuo script mi indicava c3
Comunque ho provato a dare un occhiata a sta guida.
http://guide.debianizzati.org/index...._dei_pacchetti

[~FullSyst3m~]

Qualcosa di più tecnico e approfondito a riguardo c'è? Non ho trovato nulla di particolarmente interessante.

[Gimli[2BV!2B]]

Ho impostato il wrapper di apt-build come cc, ma non è servito a nulla.

@ ~FullSyst3m~, non ho trovato niente di più di piccole guide che illustrano i passi di configurazione e invocano il magico apt-build world.

Mi lascia piuttosto perplesso dalla struttura dell'apt-build.conf.
Sono abbastanza certo che l'i486-pc-linux-gnu del configure sia corretta, trattandosi di Debian, mentre resto nell'oscurità riguardo all'Os che risultava essere l'unica flag utilizzata durante la compilazione.

Ipotesi relative al problema che ho riscontrato:

• Scelta infelice del pacchetto per fare le mie prove? (in Gentoo c'è una flag per attivare le ottimizzazioni in Xulrunner/Firefox)
• Wrapper configurato male/documentato poco?

Dcromato, durante la compilazione vedi effettivamente utilizzate la flag che hai impostato?

[Dcromato]

io si però sono su ubuntu...ma non è che il comando che hai dato:

apt-build --remove-builddep --noupdate xulrunner-1.9 iceweasel

manca di qualcosa?so che ci dev'essere un comando primario come install o upgrade

[~FullSyst3m~]

Originariamente inviato da Gimli[2BV!2B]

Ho impostato il wrapper di apt-build come cc, ma non è servito a nulla.

@ ~FullSyst3m~, non ho trovato niente di più di piccole guide che illustrano i passi di configurazione e invocano il magico apt-build world.

Mi lascia piuttosto perplesso dalla struttura dell'apt-build.conf.
Sono abbastanza certo che l'i486-pc-linux-gnu del configure sia corretta, trattandosi di Debian, mentre resto nell'oscurità riguardo all'Os che risultava essere l'unica flag utilizzata durante la compilazione.

Ipotesi relative al problema che ho riscontrato:

• Scelta infelice del pacchetto per fare le mie prove? (in Gentoo c'è una flag per attivare le ottimizzazioni in Xulrunner/Firefox)
• Wrapper configurato male/documentato poco?

Dcromato, durante la compilazione vedi effettivamente utilizzate la flag che hai impostato?

Al momento non mi interessa molto la cosa, mi informerò in un secondo momento.

[Dane]

con gcc aggiungi -pipe -fomit-frame-pointer (perdi possibilità di debug ma sono flags sicure), usa O2, di più non ha senso

Se intendi giocare tanto con ricompila gcc e glibc(magari solo con le localizzazioni che ti servono), che magari in seguito stai meno tempo a compilare



se puoi usa icc al posto di gcc (fino a +20%) (ma attento alla licenza dei binari ottenuti)



per ottimizzazioni più spinte, imho, non ne vale la pena, a meno di dover tirare su un cluster di calcolo (per elaborazioni MOLTO specializzate) in cui anche il 3% di incremento di prestazioni è importante.



PS: se hai tanta ram COMPILA IN RAM!!!!! fa miracoli.
poi usa ccache, per non dover ri-buildare le stesse cose n volte!

[Gimli[2BV!2B]]

@ Dcromato, ho copiato male, stavo litigando con Konsole 4.2.2-1... dannata, se si chiude un tab ci si gioca il menù destro, in automatico vado di ctrl C per copiare, ma naturalmente non è la scelta migliore...

Ho fatto un paio di prove con delle pulci di pacchetti (most e dash), durante la compilazione l'unica flag attivata è l'On:

[most...]
gcc -c -O2 -g -Wall -DUTF8  -Dunix  -DMOST_SYSTEM_INITFILE='"/etc/most.conf"'  /var/cache/apt-build/build/most-5.0.0a/src/most.c
[...]
[dash...]
gcc -DHAVE_CONFIG_H -I. -I../../src -I..  -include ../config.h -DBSD=1 -DSHELL -DIFS_BROKEN  -Wall -g -O2 -Wall -MT histedit.o -MD -MP -MF ".deps/histedit.Tpo" -c -o histedit.o ../../src/histedit.c
[...]

Ora sto provando bash (che builddep bizzarre... texlive-latex-base-doc?)
Pure qua solo O2:

gcc -c  -I. -I../.. -I../../../bash -I../../../bash/lib -I../../../bash/include -I../../../bash/lib/sh  -DHAVE_CONFIG_H -DSHELL  -g -O2 -Wall   ../../../bash/lib/sh/shtty.c

Certo l'O2 non è da buttare, ma vorrei capire perché non vengono utilizzate la altre flag. Perché tutte le librerie collegate al programma andrebbero ricompilate con le stesse opzioni, quindi vengono eliminate d'ufficio? È colpa degli alieni?

Resta che la ricompilazione di Iceweasel/Firefox-Xulrunner sembra imporre l'utilizzo di Os, rendendo di fatto la cosa una pura e semplice perdita di tempo (si vede che son di cattivo umore?).

Vabbè, credo proprio che ora lo disinstallerò e non proverò più a trasformare la mia amata Debian in Gentoo.

P.S. --remove-builddep non mia ha rimosso le builddep installate ad apt-build.

[Dcromato]

Originariamente inviato da Gimli[2BV!2B]

P.S. --remove-builddep non mia ha rimosso le builddep installate ad apt-build.

quoto, e la cosa mi scoccia alquanto