Newsgroup: it.comp.os.linux.iniziare
Titolo: domanda su src.rpm

Scusate se le domande sono banali, ma pur essendomi avvicinato a linux da 
ormai un pņ di mesi, ho alcune lacune "concettuali" che spero di rimediare 
col vostro aiuto. 
Un pacchetto src.rpm una volta lanciato con rpm --rebuild produce un 
pacchetto rpm: 
1) che differenza c'č rispetto agli rpm precompilati? Questo pacchetto 
diventa "ottimizzato" per il mio kernel? 
2) se io prendo un src.rpm pensato per un'altra distribuzione (come da 
indicazione di 
rpm.net
) e lo compilo va bene per la mia distro oppure 
continua ad essere adatto solo alla distribuzione di partenza?
Grazie
Marcello / arrovellato dai dubbi :-)
mdk8.0
-- 
antispam
ab...@libero.it
ab...@tin.it

 continua ad essere adatto solo alla distribuzione di partenza?
Sì e no. Non è corretto dire che viene ottimizzato per il tuo kernel, ma
sicuramente ottieni un package costruito esattamente per le librerie che hai
installate.
Per esempio un package che ha come dipendenza le gtk+ > 1.2.0 probabilmente
è compilato proprio con le 1.2.0. Se tu hai la 1.2.8, il package sarà
compilato con la tua versione. Per contro, potrebbe anche succederti di non
riuscire a compilare (proprio per leggere differenze tra librerie), un
package il cui precompilate invece più o meno gira.
Per quanto riguarda il passaggio tra distro e distro, anche i src.rpm sono
preparati per adeguarsi alla distro, a meno che non ci siano script che
riconoscano la distribuzione e modifichino di conseguenza i Makefile.
La vera utilità e quendo per esempio trovi un package compilato con le
glibc2.2 (redhat7) e lo vuoi installare su un sistema glibc2.1 (redhat6.2).
In questo caso i binari non funzionerebbero proprio, quindi i src.rpm sono
l'unica soluzione.

 continua ad essere adatto solo alla distribuzione di partenza?
Gli rpm sono differenziati da distro a distro perche` alcune usano posti
diversi per certi file, cercano le librerie in posti diversi ecc ecc
Per cui alcuni sono compatibili e altri no.
L'altro giorno ho scaricato un programma in rpm, poi con alien ho
provveduto a trasformarlo in .deb, e si e` installato bene, funziona, in
altri casi non ha funzionato....stesso vale fra rpm di diverse distro.
Comunque io ti consiglio di usare una distro che si appoggi sul package
manager di Debian ( .deb quindi ), perche` e` assolutamente superlativo.
Debian liscia come prima scelta, ma ce ne sono altre, ora sto scaricando
Progeny ( 
www.progeny.com
 ) che e` una Debian modernizzata, provala
dicono sia ottima.
Ciao, `matte.
-- 
err: signature too big

 librerie che hai installate.
Ah no? Io pensavo che compilando un pacchetto su kernel con specifico
supporto per i686, si ottenesse un pacchetto per i686 e che quindi non
funzionasse per i386....
Ho sentito dire a qualcuno che avendo compilato parecchi programmi su
P3, sarebbe traumatico passare ad un Athlon perche` necessiterebbe di
ricompilazione il pacchetto (non solo il kernel).... come mai?


 
Non direttamente con rpm --rebuild come ha chiesto lui: anche con una cpu i686
ottieni un eseguibile della famiglia i386. La vera ottimizzazione si ha verso
le varie librerie dinamiche del tuo sistema, che possone essere di versioni
diverse da pc a pc. Risulta necessario anche per avere eseguili compatibili
con piattaforme non i386 (tipo sparc), cmq non si ha nessuna ottimizazione in
base alla versione del kernel, a meno che ovviamente non sia un software che
ha bisogno delgli headers del kernel per compilarsi.
-- 
--------------------------
Francesco Tosi
frances...@seabone.net
frt...@tin.it
--------------------------

 solo alla distribuzione di partenza?
dipende, se ha la stessa architettura sicuramente si, penso che
gli rpm-src siano il tarball originali e le diff della distribuzione
(come in debian), eventualmente verifica i diff

 software che ha bisogno delgli headers del kernel per compilarsi.
Ah... trasferisci la risposta sotto il mio reply a Lone, qui sotto...se
puoi.


 cambiando i settaggi predefiniti di gcc
Tell me More, please!!
Un momento, ma vuoi dire che tutto quel che ho compilato da deb-src e`
tutto per i386?? Non dirmi di si...senno spacco tutto ;)))


 continua ad essere adatto solo alla distribuzione di partenza?
        Credo di no.
 
        Ciao, Giovanni.
-- 
   |^^^^|
   |    |  Eat my shorts !             * Linux Powered *
   |()()| /                            - Kernel  2.4.4 -
                 -> gio.bcc(at)
tin.it
 <-

  installed-size: 16
Interessante, grazie della dritta!
Ah, un ultima cosa... se compilo tutto per i686,e poi passo ad athlon,
che succede? E` compatibile o devo ricompilare tutto?


 che succede? E` compatibile o devo ricompilare tutto?
i386 gira su un athalon? ^_^ 
certo, mantengono la compatibilità verso il basso, ma gli AMD hanno
tutta una serie di istruzioni in più (3d now per esempio) o
ottimizzazioni del mtr che non vengono sfruttate appieno

 ottimizzazioni del mtr che non vengono sfruttate appieno
Ecco, quindi compilo per athlon --> sul p3 non ci sono le 3dnow e quindi
non gira; compilo per p3 ----> non gira su athlon perche` non ci sono le
SSE?


 SSE?
Anche  a   me  interessa  molto  l'argomento. Tra   l'altro  ho  ri-visitato
recentemente  il   sito  
http://www.athlonlinux.org/
   ma  non   viene  piu`
aggiornato da ottobre.
Ogni tanto  nei siti  o nelle  mailing list dedicate  a debian  spuntano dei
dibattiti relativi all'opportunita` o meno  di ricompilare i programmi per i
processori dell'ultima generazione,  al posto di aver tutti  i pacchetti per
i386. Poi pero` c'e`  chi dice che non ne vale  la pena perche` l'incremento
prestazionale ottenuto non ripagherebbe il lavoraccio svolto. Inoltre alcuni
puntano il dito  sul fatto che si otterrebbe un  sistema potenzialmente meno
stabile.
Ma, lo scopriremo solo vivendo. Tu hai per caso provato il pacchetto
pentium-builder?
Saluti,
Tiziano. 
-- 
Togli ABC per rispondere via email.
*********** 
http://www.sarlak.f2s.com
 **********
"And the whole world could have passed through me
But I don't know that it means much to me"

 pentium-builder?
si, io lo uso da sempre, ma non so dirti le differenze, non ho fatto
tests comparativi e i pachetti li compilo per me

 SSE?
Spinto dalla curiosita` ho provato ha fare un piccolo test casalingo
compilando il lame encoder versione 3.88beta (la piu` recente).
Versione standard
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA 
  8308/8308  (100%)|    0:45/    0:45|    0:45/    0:45|   4.8206x|    0:00 
Versione "ottimizzata"
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA 
  8308/8308  (100%)|    0:40/    0:40|    0:40/    0:40|   5.3772x|    0:00 
Nel secondo caso ho usato queste ottimizzazioni:
CFLAGS="-s  -O3  -fomit-frame-pointer -Wall  -mpentiumpro  -march=pentiumpro
-malign-functions=4 -funroll-loops  -fexpensive-optimizations -malign-double
-fschedule-insns2 -mwide-multiply"
Alcuni dati sul mio sistema:
Athlon 800, 256Mb Ram
Debian Woody
Kernel 2.2.19
gcc            2.95.3-7


 tests comparativi e i pachetti li compilo per me
A me interessava giusto per sapere, se quei pacchetti che tengo
aggiornati da unstable, siano da tenere sott'occhio nel caso di cambio
d'architettura, non li compilo certo per migliorare le performances ;)


 gcc            2.95.3-7
2.95.2


 Come e` possibile cio`?
Hai impostato la variabile DEBIAN_BUILDARCH=pentium ? Se non la imposti non
modifichi il comportamento di gcc.


 imposti non modifichi il comportamento di gcc.
Si, l'avevo fatto, ma e` come se non venisse considerata; quando compilo
infatti non vedo nessuna parola "pentium" a monitor....
gcc -DHAVE_CONFIG_H -I../include -I. -I../libmp3lame -I.. -O3
-fomit-frame-pointer -ffast-math -funroll-loops -mfancy-math-387
-pedantic -Wall -pipe -c layer1.c -Wp,-MD,.deps/layer1.TPlo -o layer1.o
Invece compilando con il CFLAGS="I_tuoi_settaggi", ottengo:
gcc -DHAVE_CONFIG_H -I../include -I. -I../libmp3lame -I.. -O3
-fomit-frame-pointer -ffast-math -funroll-loops -mfancy-math-387
-pedantic -Wall -pipe -s -O3 -fomit-frame-pointer -Wall -mpentiumpro
-march=pentiumpro -malign-functions=4 -funroll-loops
-fexpensive-optimizations -malign-double -fschedule-insns2
-mwide-multiply -c interface.c -Wp,-MD,.deps/interface.TPlo -o
interface.o
Cosi` scende da 1.09 a 1.04 il tempo di codifica, ma resta il fatto che
il pacchetto pentium-builder e` come non esistesse....
E poi, con questi CFLAGS, ottengo il massimo dell'ottimizzazione, o il
pacchetto sopra citato dovrebbe farmi guadagnare ancora qualcosa?


 tempo. Mah!
 The way this package works is it diverts gcc, cc, g++, etc, with shell
scripts that, if the environment variable DEBIAN_BUILDARCH is set and
exported, call "gcc -m$DEBIAN_BUILDARCH". So with DEBIAN_BUILDARCH=pentium
set and exported, you build pentium optimized binaries, without it set, you
build normal i386 binaries.
leggere la documentazione pare brutto ;-)

 leggere la documentazione pare brutto ;-)
No, lo fatto eccome, ma non si ottimizza, il tempo e` uguale alla
compilazione normale, e quando compilo non vedo nessun riferimento a
pentium, ergo non e` compilato per pentium.
Se io setto $CFLAGS come ha fatto tiziano, guardagno 5sec, ma quel
pacchetto non ha comunque nessun effetto.


> No, lo fatto eccome, ma non si ottimizza, il tempo e` uguale alla
     ^^^^^
Scusate, e` l'ora :P

 pacchetto sopra citato dovrebbe farmi guadagnare ancora qualcosa?
Non so quali flag passi al gcc il pacchetto pentium-builder. Fatto sta
che preferisco  settare personalmente  le varie  ottimizzazioni quando
voglio fare  degli esperimenti. Certo che,  sarebbe interessante poter
testare un sistema con, se  non tutti, almeno i programmi maggiormente
"cpu-dipendenti" ricompilati  per sfruttare  al meglio (nel  mio caso)
l'Athlon e le 3dNow.
Comunque a questo indirizzo trovi altri test:
http://aboutlinux.com/art_k7opt1_a.html
