Newsgroup: it.comp.os.linux.iniziare
Titolo: GTK+ 2.4.1 - A proposito di dipendenze

Buongiorno a tutti.
Qualcuno ha compilato le GTK+ versione 2.4.1? Se si, potrebbe gentilmente
confermarmi che per compilare tali librerie correttamente occorre compilare
anche le seguenti?
Grazie della delucidazione.
Francesco
-----------------------------------
expat-1.95.7
zlib-1.2.1
libpng-1.2.5
tiff-3.6.0
autoconf-2.59
automake-1.8.4
libtool-1.5.6
xfree86-4.4.0
Glib-1.2.10
libxml2-2.6.8
giflib-4.1
jpeg-6b
gettext-0.14
libiconv-1.9.1
gtk+-1.2.10
imlib-1.9.14
icewm-1.2.13
glib2-2.4.1
atk-1.6.0
pango-1.4.0
Ed infine....
gtk+-2.4.1


Mi pare proprio di no. Perche' mai le gtk+ dovrebbero dipendere da pango o
da icewm? Semmai e' il contrario. Che io sappia (e da quello che mi dice la
mia fedora) le cose richieste per gtk+ sono solo glib e, ovviamente, glibc.
Per compilare pero' ci vogliono anche make e un compilatore.
-- 
Enrico Bodo  -  Assistant Professor in Theoretical Chemistry 
University of Rome "La Sapienza" 
Department of Chemistry         

 da icewm? Semmai e' il contrario. Che io sappia (e da quello che mi dice
la
ICEWM mi sembra strano anche a me... ma Pango lo vuole ed č anche
specificato nel README!
Una domanda diretta: Siccome tutto 'sto compilare č il preludio alla
compilazione di fvwm, alla fine le GTK sono riuscito a compilarle; peccato
che fvwm quando faccio ./configure non le veda!
Sono sicurissimo di aver trascurato qualche oscuro "make qualcosa" che mi
trasferisce qualche altro pezzo in qualche sperduta directory o in qualche
variabile d'ambiente non ho settato il valore.... So di essere stato
schifosamente vago, ma per uno che ha fatto ./configure, make, make install
hai qualche suggerimento da dare a pelle?
Ciao!
Francesco

 hai qualche suggerimento da dare a pelle?
Usare binari precompilati. :-)


 Usare binari precompilati. :-)
Ma, sai! Con la mia cultura di linux dovrei usare una bella RedHat; o
meglio: L'ho installata una volta; mi sono trovato l'ambiente
preconfezionato pieno di cappellini rossi su cui non sapevo mettere mano.
Senza contare che alcune cose non funzionavano comunque... (
p.es
. MySQL
piuttosto che apache li ho dovute reinstallare).
Ciao!
Francesco

 gtk+-1.2.10
E no.
+++
Posto l'avere gli autotools, make e X installati, per le GTK 2.4 hai
bisogno (nell'ordine) di compilare:
	* pkg-config
	* glib
	* atk
	* pango
	* gtk
Fine.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 che fvwm quando faccio ./configure non le veda!
Abbastanza ovviamente, direi, dato che Fvwm non usa le GTK.


 Abbastanza ovviamente, direi, dato che Fvwm non usa le GTK.
....allora non capisco come mai quando faccio il ./configure alla fine mi
esca fuori una dicitura del tipo:
.....
With GTK+ required for FvwmGtk? no: Failed to detect GTK, see config.log
.....
Magari non sono fondamentali (anzi, sicuramente, visto che fvwm poi gira!)
perņ la cosa bizzarra č che le ho installate e non le vede!
Ciao!
Francesco

 * glib
...e proprio sulle GLIB, dopo la compilazione ho eseguito il test con "make
check" e.... 2 test su 37 sono falliti! Perché? Boh! Sembra che non trovi
alcuni file... la caccia prosegue!
Scusami, ma non capisco proprio come mai mi dici "...vuoi farti del male!";
onestamente mi sembra il modo più veloce (anche se non indolore) di capire
cosa ci stia dietro una distribuzione e all'occorrenza saper intervenire per
aggiornamenti / ottimizzazioni di un modulo.
Suggerimenti und incoraggiamenti benvenuti!
Ciao e grazie!
Francesco

 preconfezionato pieno di cappellini rossi su cui non sapevo mettere mano.
E adesso hai un sistema non preconfezionato su cui non sai mettere mano
ugualmente. Il che non mi sembra un guadagno anzi...


 aggiornamenti / ottimizzazioni di un modulo.
No, e' il modo piu' complicato di avvicinarsi a linux. Per capire cosa sta
dietro una distribuzione basta usarla e risolvere i (pochi) problemi che si
incontrano volta per volta. Inoltre distribuzioni un minimo evolute hanno
metodi molto piu' furbi di aggiornare il software che non compilare e
riempirsi il disco di header.


 ugualmente. Il che non mi sembra un guadagno anzi...
Si può mettere mano imparando quello che la distribuzione ti nasconde.
Una distribuzione ti mette insieme applicazioni e librerie pronte all'uso;
quando devi aggiornare qualcosa come fai? Scarichi i sorgenti e te li
compili, oppure scarichi il precompilato e te lo installi da zero; peccato
che non avendolo mai fatto non lo sai comunque e non hai a disposizione
neanche quelle informazione che avresti raccolto costruendoti da te il
sistema.
Caso pratico: E' dal 1998 che lavoro con una certa assiduità su windows e
ancora non ho capito tutti quei processi che girano in background cosa
stanno a significare! Ogni tanto me ne salta fuori qualcuno che chiede un
accesso ad internet (per far che?? chi è?? che vuole??) e non so cosa fare!
Il bello è che neanche la hotline M$ sa cosa sono!
Non voglio ricadere su questo problema e su quello che ti cito nel prossimo
post!
Ciao!
Francesco

  post!
E` architetturalmente diverso. Con (quasi) qualsiasi distribuzione,
Lindows e poche altre apparte, apri un'emulatore di terminale e puoi
modificare tutto quanto ti aggrada.
Cio` detto, buon corelinux.
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky

 riempirsi il disco di header.
Sicuro! Il problema è che se cambi distribuzione quei meccanismi evoluti non
è detto che ce li abbia ancora!
Cosa fai? Panico?? Di fronte al cliente gli dici "se non mi fai trovare la
RedHat con l'RPM non lavoro"?
No, giochi alla vecchia maniera.
Altrimenti hai il solito sistemino chiuso tipo windows che vedi una bella
interfaccia grafica e non sai cosa ci sta dietro.
Ciao!
Francesco
P.S.: Ma il problema è un'altro... tanti README e tanti INSTALL sono solo
"generic installation procedures" e tralasciano dei dettagli che servono e
che nessuno sembra sapere, ringraziando le distro che ti fanno trovare la
pappa pronta.

 Cio` detto, buon corelinux.
Grazie! ;-)
Francesco

  Sempre che tu sappia cosa gira effettivamente sulla tua macchina.
E perche` mai non dovrei saperlo? =:|


  pappa pronta.
Da dare ./configure && make && make install (senza pensare ad altro)
a rpm -ivh non vedo tutta 'sta gran differenza, all'atto pratico.


 pappa pronta.
Il fatto che tu non sappia bene come funziona Corelinux o piu' in generale
i pacchetti tar.gz e tutta la trafila della compilazione e' comprensibile
perche' nessuno nasce imparato, ma imputarla a Redhat sinceramente lo trovo
infantile.
Quei dettagli di cui parli sono un bagaglio normale di un utente un po' piu' 
esperto. Mi sembra che tu abbia deciso per la strada difficile, ma che
pretenda una mappa dettagliata della via. Le strade difficili sono difficili
proprio perche' non c'e' sempre una mappa. 


 però la cosa bizzarra è che le ho installate e non le vede!
*Dove* le hai installate?
Prova ad usare LD_LIBRARY_PATH o PKG_CONFIG_PATH, ad esempio (10 a 1 che
si tratta di quest'ultimo).  In ogni caso, scartabella tra le opzioni
dello script "configure", usando:
	configure --help
Per vedere se esiste uno switch in grado di forzare la posizione delle


 E perche` mai non dovrei saperlo? =:|
Caso personale: Ho installato diverse distribuzioni e ognuna mi dava una
serie di scelte possibili sui pacchetti da installare con nome ed una breve
spiegazione; per mia ignoranza sono andato ad installare una serie di
pacchetti che in realtà non mi servivano ma che però ho installato con la
paura del "...se poi non funziona senza!". A questo punto ho ottenuto un
sistema molto simile ad una installazione tipica di windows, dove ho una
scatola chiusa con gran parte del sw installato che non mi servirà mai.
Ho reso l'idea?
Francesco

 aggiornamenti / ottimizzazioni di un modulo.
No: tu stai *scientemente* facendoti del male, dato che *non* conosci
Linux.
Partire "from scratch" senza sapere nulla è l'equivalente di martellarsi
i coglioni con il martello di Grahbtar.
Segui il consiglio: installati una distribuzione, *imparala*,
distruggila, e poi - se e quando avrai imparato - parti con una distro
"from scratch".


 GTK.
Si, c'è --prefix che ho impostato su /usr/local come tutte le altre
librerie.
Ciao.
Francesco

 a rpm -ivh non vedo tutta 'sta gran differenza, all'atto pratico.
rpm ti costringe a usare un prg di gestione che si chiama RedHat Package
Manager che installa programmi; se hai bisogno di un programma che non
esiste in .rpm devi comunque andare di sorgenti.... quindi tanto vale
affrontare subito l'annoso problema della compilazione.
Ciao!
Francesco

 Tanto vale esserne a conoscenza subito, no?
Sei sicuro di non stare trollando? No, perché da qui sembra.


 proprio perche' non c'e' sempre una mappa.
La differenza fra difficile e facile è nel sapere o non sapere. La mappa c'è
sempre perchè 'sti benedetti prodotti qualcuno li ha installati e con
successo (altrimenti sulle distro non girerebbero), quindi se la mappa non
esiste è perché qualcuno non l'ha voluta tracciare! ;-)
Del resto, se tutti si scaricassero e utilizzassero i componenti che servono
per avere un sistema funzionante, mi spiegate:
- a cosa servono le distribuzioni e le software house che le mettono in
commercio?
- a cosa servono gli "evangelist" che si vendono alle aziende per
personalizzare le distribuzioni?
Scusate le polemiche finali, ma alla fine il "potere" nel senso più ampio
del termine è la differenza fra conoscere e non conoscere!
Ciao!
Francesco

 Sei sicuro di non stare trollando? No, perché da qui sembra.
No, guarda!
Mi sta venendo la tendinite per cercare di spiegare un modo di pensare ed
agire... se la metti su questo piano tagliamo qui subito!
F.

 "from scratch".
Non capisco perché devo partire da un qualcosa per poi distruggerla e
ricostruirla....
Ciao!
Francesco

 ricostruirla....
Ammetto che "distruggila" è stata /too strong a word/. "Smontala", ad
esser sinceri, andava meglio.


 Siamo sempre li! Devo essere vincolato ad UNA distribuzione?
Perché *una*? Quello che impari lo puoi applicare ad una *classe* di
distribuzioni.
Non so che idea strana ti sei fatto, ma:
	1. se installi dai sorgenti, avrai un'installazione talmente
	custom da essere solo in teoria compatibile con il resto del
	mondo là fuori;
	2. fai uso dei sorgenti su una distribuzione pacchettizzata,
	e stai pur sicuro che *niente* - nemmeno gli spiriti della
	minchia - riusciranno a salvarti in caso di aggiornamento;
Quindi, se per te "imparare" significa "cagare chiodi e bulloni per
benefici solo in parte verificabili", allora vai pure avanti.


 Prima o poi devi spendere tempo per impararlo... preferisco spenderlo prima.
L'approccio e' sbagliato. Io continuo ad insistere che avresti imparto molto di
piu' a far funzionare apache su redhat o slackware che sono due sistemi
perfettamente aperti, anzi a giudicare dalla quantita' di documentazione che
c'e' in giro direi molto piu' aperti di Corelinux.


 affrontare subito l'annoso problema della compilazione.
Ma perche' andare a pescare Corelinux? Non puoi compilare quello che vuoi su
redhat? E' uguale. 


 impararlo prima che affrontare degli imprevisti dopo!
Il futuro (e il presente) delle distro GNU/Linux è un sistema che gestisce i
pacchetti come fanno rpm, yum, apt-get, emerge, urpmi, ...
Ha poco senso credere che il modo migliore di "imparare Linux" sia risolvere
le dipendenze manualmente, è una scocciatura che fa perdere più che altro
un sacco di tempo; sono stati creati degli ottimi software proprio per
rendere più facile l'installazione dei programmi pacchettizzati,
risolvendone le dipendenze; le competenze rilevanti riguardano la
configurazione ottimale dei programmi, non tanto la loro compilazione.
I sistemi di pacchettizzazione *non* impediscono all'utente di guardare cosa
c'è "sotto il cofano"; se uno dei tuoi obiettivi è imparare come funzionano
le varie distribuzioni, mettiti nell'ottica che l'installazione (o
addirittura la compilazione) è delegata ad un software apposito, diverso
per ogni distro (rpm per Red Hat e SuSe, apt-get per Debian, emerge per
Gentoo, ...). Vale la pena, quindi, cercare di capire qual è la logica di
fondo di questi package manager: alla fine fanno grosso modo le stesse
cose: cercano nel database dei pacchetti, risolvono le dipendenze,
installano, rimuovono... Ognuno con il proprio set di comandi.
Una volta imparato il concetto su una distro, per passare ad un'altra dovrai
solo imparare _come_ si fa (ma saprai già _cosa_ vuoi fare). Senza contare
che compilare & installare software su una distro basata sui pacchetti non
è un'idea brillante, prova il fatto che sono stati creati programmi tipo
checkinstall che si occupano proprio di creare e installare il pacchetto
dopo aver lanciato il make install.
Se ti da fastidio che un installer come Anaconda decida quali pacchetti
installare, ti consiglio di provare Gentoo (
http://www.gentoo.org/
): ti fa
capire molto bene il processo di installazione e ti permette di
personalizzare il software installato fino alla nausea; l'ottima
documentazione, esauriente fino a sfiorare il wizard, ti guiderà passo
passo nella creazione della *tua* Linux box.
Tutto questo, ovviamente, IMHO  :)
-- 
Faber
http://www.faberbox.com
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it. -- Brian W. Kernighan

  Ho reso l'idea?
Onestamente? No, o perlomeno molto vagamente.
PS: con tutto questo non voglio dirti di usare RedHat o chiccessia.
Utilizza quel che vuoi, ovviamente. Mi sembra pero` che ci siano in giro
alcuni (falsi) miti che avrei piacere di contribuire a debellare.


  affrontare subito l'annoso problema della compilazione.
La compilazione non e` un'annoso problema, farsi gli rpm a mano e`
comunque meglio che installare i sorgenti nudi e crudi (ma per
farlo occorre sapere come lavora rpm).
Inoltre, per risolvere detto annoso problema, specie su una distro
rpm-based occorre sapere cosa c'e` nel sistema, dove sta ed eventualmente
come funziona.
In altre parole, occorre comunque imparare ad usare il package managere :)
PS: con tutto questo non voglio dirti di usare RedHat o chiccessia.
Utilizza quel che vuoi, ovviamente. Mi sembra pero` che ci siano in giro
alcuni (falsi) miti che avrei piacere di contribuire a debellare.
-- 


  ricostruirla....
Perche` questo e` un (ottimo, IMHO) modo di imparare.
Per imparare a paciugare nei motori, o in ogni congegno meccanico, si
smontano e si rimontano, per capire "chi e` chi", "chi fa cosa" e di riflesso
dove agire per migliorare (= adattare a specifiche esigenze) le cose.
Non credo che iniziare da zero fondendosi il proprio motore
sia un'approccio cosi` drammaticamente migliore.
