Newsgroup: it.comp.macintosh
Titolo: disastro installazione librerie qt

Ciao a tutti,
sto tentando da qualche giorno di installare sul mio ibook con OSX 
10.3.3 le librerie QT 3.3.1 (quelle di Trolltech, non quicktime) 
versione free, ma non ci sto riuscendo: pur seguendo le istruzioni alla 
lettera (impostare variabili d'ambiente, configure con i flag 
appropriati e make) ottengo due esiti: kernel panic (vergogna apple, 
cosa veramente inaccettabile: com'è possibile che un processo a livello 
utente - make - provochi un crash di sistema? stiamo tornando ai livelli 
di windows 95) o esotici errori di compilazione (in altri rari casi). 
Inizio a pensare che sia un problema del gcc incluso nei developer tools.
Qualcuno di voi è riuscito a installare queste librerie? Ho cercato in 
giro, anche sui forum di trolltech, ma non ho trovato niente di utile...
Grazie in anticipo per l'aiuto

 versione free, ma non ci sto riuscendo: 
boh
a suo tempo per installare grass le avevo installate tramite fink senza
troppi problemi mi pare
-- 
ciao
chris
www.christian.pacher.name
www.ihm-bz.it

 wrote:

Io ho installato quelle native per aqua e non mi han dato nessun
problema. Dovresti dirci che errori ti vengono proposti e che
compilatore stai usando, io con il gcc 3.3 non ho avuto alcun problema.
Ben strana la storia dei kernel panic, come giustamente fai notare un
processo utente non dovrebbe arrivare a tanto ...
-- 
Ciao
Fabio

 Qualcuno di voi è riuscito a installare queste librerie?
si. esattamente con *quel* compilatore.
al limite prova a disabilitare le librerie condivise.
e cmq imho hai qualche grossa crisi con i path in cui cerca le librerie
o con le versioni stesse... ma casini antecedenti a QT, intendo.
-- 
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

 
la macchina è abbastanza pulita, le variabili d'ambiente sono tutte a 
posto, ho sempre evitato di fare cose strane e c'è poco software 
installato...

 installato...
sono quasi convinto che la chiave di volta sia -shared.
ho visto spesso problemi con le lib dinamiche sotto il macos x [ per
librerie che venivano da mondo unix]. o meglio, spesso e` grossa...
piuttosto talvolta.
cmq se poi vuoi distribuire il sw, ti conviene comunque usare binari con
qt statica, visto che la maggior parte dei macchisti non le ha
installate.
e tu dirai che per i programmi che ti vuoi tenere tu e` una briga... e
io ti diro` che hai ragione.



-- 
Ciao
Fabio


bellissimo link


 make: *** [init] Error 2
quest'errore l'ho avuto un paio di volte...
ho provato poi a compilare tutto nella mia home directory, usando il 
./configure senza alcun flag, e mi va sistematicamente in kernel panic 
dopo un minuto scarso (prim'ancora di lanciare il make). Per curiosità 
ho provato a installare le qt via fink, ma anche lì ottengo un kernel panic.
in quest'ultimo periodo il mac mi ha dato parecchie noie, safari crasha 
spesso, quicktime e vlc mi hanno prodotto pure loro dei kernel panic, 
inizio a pensare che questo 10.3.3 contenga codice sorgente di windows.. 
mi sa che faccio tabula rasa e reinstallo tutto sperando che esca 
rapidamente il 10.3.4.
cmq grazie a tutti per l'aiuto.

 
Questo e' vero il vantaggio che puoi compilare le librerie e
l'applicazione separatamente, in teoria sovrascrivi la cartella con il
framework e la tua applicazione usa le nuove Qt senza cambiare una riga
di codice dell'applicazione.
I
-- 
Ciao
Fabio

 rapidamente il 10.3.4.
a beh... allora diciamo che i problemi erano alla base :)
probabilmente puo` bastarti un archivia e installa...
cmq io pure ho il 10.3.3 e nessun problema di sorta. certo, smacchinando
nel sistema, il rischio di fare danni c'e` sempre :)


 l'applicazione separatamente,
vero... oggi ho appena fatto due prove con un mio amico (ciao whamoo :)
).
lui ha le qt dinamiche.
lo stesso programmino [ C++ ], un affare da poche righe di codice, con
pochi pulsanti ecc [ ma tuttavia da bene quello che deve fare ], da me
impiegava meno della meta` del tempo ad avviarsi.
Lui ha un pb 1GHz, io l'867... quindi macchine confrontabili.
Mi piacerebbe vedere se con un'app grossa il divario si restringe...
ovviamente sul mio l'eseguibile era 7 MB, sul suo 700 KB ;)


 
E devi vedere che bello quando lanci PyQT .... parte la pausa caffe!
penso di avere anche io le Qt dinamiche, non mi ricordo avevo seguito le
istruzioni per la compatibilita' con KDE, e non ho fatto molto caso alla
cosa ( a parte metterci i soliti -mcpu=7450 -maltivec -faltivec che non
guastano mai :-).
-- 
Ciao
Fabio

 ovviamente sul mio l'eseguibile era 7 MB, sul suo 700 KB ;)
Gia' le qt dinamiche fanno a dir poco schifo in fase di esecuzione!!!
Pero'  se usate statiche sono accettabili, poi sono ottime librerie
portabilissime...
Io le ho compilate piu' volte ma non mi hanno mai dato problemi in fase
di compilazione...
Whamoo

 guastano mai :-).
ecco... io quelli non li metto... in linea teorica non dovrebbe sgamarli
automaticamente il compilatore?


 di compilazione...
hai poi risolto il problema che dovevi per forza compilare dentro la
cartella qt?
se si, hai poi capito dove era il problema...



Se funziona la mia mail e' valida :-)
 
-- 
Ciao
Fabio

 automaticamente il compilatore?
Non penso che sia cosi' furbo e poi penso che sia pensato per avere il
piu' ampio numero possibile di target e con questi flag limiti le
macchine praticamente solo ai G4 (anche sui G5 dovrebbe andare ma non ho
mai provato).
-- 
Ciao
Fabio

 Se funziona la mia mail e' valida :-)
appena ho un minimo di tempo...


 mai provato).
anche questa e` una buona analisi... bisognerebbe vedere nella
documentazione quale livello di -O e` quello di default [ o meglio..
quello si sa, poi spesso nei ./configure imho si usa cmq -O2 ] e che
flag sono abilitate...
ma non ho voglia di ricompilarmi tutte le qt... :(


 se si, hai poi capito dove era il problema...
No, ancora ora devo compilare i miei sorgenti li dentro, se provo a
usare il qmake fuori dalla loro cartella mi da' un sacco di errori di
undefinied simbols.......bha, vai a sapere il perche'.... cmq e' un
errore di path ne sono sicuro, e' che non riesco a risolverlo... =P
Whamoo

 > se si, hai poi capito dove era il problema...
Oks, visto che non avevo sonno e null'altro da fare, mi sono messo li a
capire perche' non funzionavano.... mi sono letto i makefile creati e ho
visto che con piccole modifiche mi funzionavano.... Morale della favora
esportavo $QTDIR nel path, ma non per conto suo, quindi a ragion veduta
non compilava visto che il makefile era pieno di ($QTDIR)/blabla...
Errore grossolano, ma per qualche perverso motivo non sono riuscito  a
vederlo per un bel po' di tempo =P
Ah poi mi sono accorto che facendo un link delle librerie dinamiche in
/usr/lib vanno appena piu' veloci, ma niente in comparazione a quelle
statiche, peccato che le statiche aggiungano 7 mb all'eseguibile =P
Whamoo

 statiche, peccato che le statiche aggiungano 7 mb all'eseguibile =P
finche` pero` non saranno incluse nell'os, dovresti comunque
distribuirle... quanto pesano ''nude''?


 distribuirle... quanto pesano ''nude''?
Troppo, tanto vale usarle statiche...... Non aumentano poi cosi' tanto,
ma su applicazioni molti piccole si arriva a 8mb e mi sembra eccessivo
=P
Pero' statiche sono veramente fast'n'furiosssse, quindi mi sa che me le
ricompilo (sigh un ora di pb12" da buttare)...
Whamoo

 
La mia esperienza linux non va molto oltre ad apt-get (o urpmi in
passato) ma moltissimi sui nw python ne parlano molto bene.
-- 
Ciao
Fabio

 ma non ho voglia di ricompilarmi tutte le qt... :(
Posso capirti compilarle sul mio Dual 450 e' stata un odissea, senza
contare che appena finito sono passati pochi giorni ed e' uscita la
versione stabile, cosa vuoi fare, non metterla ? e l'odissea e'
ricominciata.
-- 
Ciao
Fabio

 Posso capirti compilarle sul mio Dual 450 e' stata un odissea
lol :)
pensa che io ho solo un portatile... 867 con disco a lumaca :)


 ricompilo (sigh un ora di pb12" da buttare)...
un ora? ma hai dato gli steroidi al bimbo?


 passato) ma moltissimi sui nw python ne parlano molto bene.
appunto... io comunque oggi ci ho lavoricchiato, e non da il boffo di un
bug.
/me prova a chiedere in mailing list, appena ha tempo di formulare il
discorso.


 un ora? ma hai dato gli steroidi al bimbo?
Guarda, ricompilate oggi, 1:30, pero' adesso le sto ancora ricompilando,
ma per errore sto compilando anche tutti i 240 programmi di test >:-(
Solo che me ne sono accorto solo ora, e ormai lo faccio finire.....
Bha, tempo persssooo
Whamoo

 pensa che io ho solo un portatile... 867 con disco a lumaca :)
:-)
-- 
Ciao
Fabio

 discorso.
Chissa' perche', le qt dovrebbero essere abbastanza stabili sotto os x e
idem python consente un buon livello di portabilita'.
Intavola intavola.
ps in quale ml ?
-- 
Ciao
Fabio

 ps in quale ml ?
quella di pyqt, pykde eric etc etc etc... sono tutte la stessa :)


 Solo che me ne sono accorto solo ora, e ormai lo faccio finire.....
a no.. io compilo sempre anche i programmi di test :)


 a no.. io compilo sempre anche i programmi di test :)
Con le shared anche io, pero' con le static perdi' solo dello spazio su
disco (e del tempo).....
Piuttosto ho notato che il designer, con le static, non mi permette di
aggiungere dei file c++, e di editare il file .ui.h da dento di
esso.....
Adesso mi ricompilo anche le shared, ilcui designer e' un po' piu'
completo (mi chiedo il perche'...) spero che il codice che generi vada
bene anche per le static, ma credo proprio di si...
Whamoo

 installate.
Ammetto di non avere ancora provato, ma se non sbaglio preparando le tue
.app con bundlebuilder dovrebbe, se serve, sapere infilare lui stesso
nel .app le librerie (e i framework) che servono.  Naturalmente questo
aiuta solo se programmi in python -- ma perche` usare altri linguaggi?-)
Alex

 Grazie in anticipo per l'aiuto
Mah, come ti dicevo a me e` andato tutto in porto senza problemi (e
anche SIP e PyQT in cima, adesso posso scrivere programmi Python con Qt,
solo GPL per ragioni di licenza, senza nessun problema sul Mac come su
Linux, e risultano pienamente portatili fra i due ambienti).
Spero di poterti aiutare a capire il perche` le cose a te non sono
andate altrettanto lisce, e a metterci rimedio...
Alex

 portabilissime...
Beh, un'applicazione puo` essere lenta a partire, certo.  Ma il
prebinding l'avete provato?  Dovrebbe (in teoria) rimediare.  Mannaggia
che ho lasciato a Bologna "Mac OS X for Unix Geeks" che sul prebinding
spende parecchie pagine (sto in Svezia, quindi al momento non posso
guardarci... se domani agli uffici di AB Strakt [dove ho la rete] mi
trovo mezz'ora libera posso provare a guardare in linea su Safari di
O'Reilly, ma mezz'ora libera in ufficio, quando sono qui a fare le mie
consulenze, mica facile che capiti...!-).
Alex

 consulenze, mica facile che capiti...!-).
lol :)


 Linux, e risultano pienamente portatili fra i due ambienti).
hai per caso provato eric3 sotto Mac?


 aiuta solo se programmi in python -- ma perche` usare altri linguaggi?-)
piano piano mi state assimilando. dannazione (e ho gia` fatto i miei
primi convertiti... :( )
appropo... al _tuo testo_ consigli di affiancare *anche* Programming
Python, o in sostanza non dice nulla che sia gia` nel tutorial etc...


 bene anche per le static, ma credo proprio di si...
hai qualche facile idea sul perche` a me da continuamente erroere? :(


 
Concordo :-)
-- 
Ciao
Fabio

 link a progetti che ne fanno uso.
mah... non ci credo che non ci siano altri programmi che fanno uso di
PyQT. E` parecchio comoda come accoppiata...
O eventualmente sto facendo io assunzioni sbagliate sulla diffusione
della faccenda.


 
Per esserci ci saranno solo che io non le conosco e Google non mi aiuta
molto perche' per lo piu' mi da siti che parlano di PyQt e di come
usarla.
Per altro di recente ho letto un intervista ai tipi di trolltech dove
trattavano abbastanza male (IMO) i binding per i diversi linguaggi, per
loro il C++ e' l'unico vero utilizzo quello nel quale Qt da il meglio di
se. Tanto e' vero che se vuoi la licenza per Qt win da usare con Python
costa meno di quella normale, te la vendono assieme a BlackAdder. Per
loro stessa ammissione il mercato degli utilizzatori diversi dal C++ e'
cosi' marginale che possono permettersi queste politiche.
-- 
Ciao
Fabio

 Python, o in sostanza non dice nulla che sia gia` nel tutorial etc...
La seconda che hai detto.  Se hai budget per altri testi consiglierei se
mai "Practical Python" di Magnus Lie Hetland.
Alex

 hai per caso provato eric3 sotto Mac?
No, non ancora.
Alex

 mai "Practical Python" di Magnus Lie Hetland.
sembra interessante.
il budget lo trovo ;)
per i libri non ho difficolta` a digiunare. manca poco che abbia piu`
libri di informatica e matematica io del mio libraio. Lui mi batte solo
perche` ne ha anche di argomenti che io non tratto, ma senno` se
restringiamo agli argomenti che mi interessano, lo straccio :)


 No, non ancora.
se ti capita, provalo.
mi pare estremamente meno stabile che sotto GNU/Linux. E mi piacerebbe
scoprire se il problema e` mio, oppure se si annida in qualche altra
cosa.


 bisognerebbe anche sentire Alex cosa ha da dire :)
Il qtclient del framework CAPS di AB Strakt, col look WinXP (brutto ma
brutto, sigh) mi e` girato al primo colpo senza problemi.  C'e` in detto
qtclient un layout manager customizzato, fatto da Strakt, che
apparentemente, a oggi, _pretende_ il look WinXP -- visto che AB Strakt
per ora non intende rilasciare CAPS per Mac [almeno sinche` non si
identifica qualche potenziale cliente, al che ovviamente le priorita`
cambierebbero all'istante], in termini di "tempo perso" non posso
proprio permettermi di mettermi a scavare nel layout manager custom e
capire dove sta il busillis.  Comunque, non mi pare che eric abbia
custom layout manager, quindi non dovrebbe essere questo (ma se dovessi
provare eric un giro per vedere se con look != Aqua funziona meglio me
lo farei, hai visto mai;-).
Alex

 hai qualche facile idea sul perche` a me da continuamente erroere? :(
L'errore a compilarti le share? Non saprei, io con le shared uso solo
l'opzione -qt-gif nel cofigure, e basta, non so che opzioni usi tu?
Whamoo

 primi convertiti... :( )
Ehi ehi, io non mi considero convertito, ho detto che come linguaggio e'
interessante, ma mi tengo ben stretto il mio C++, moooolto stretto ;-)
Cio' non toglie che come linguaggio il pyhon sia comodo, peccato non
crei eseguibili....
Whamoo

 cosa.
Bhe diciamo che avendo tu una *bash* che ci mette almeno 2 secondi per
avviarsi, direi che qualche problemiccio causa uso intensivo ce lo
protesti anche avere =)
Whamoo

 
[ cut ]
Accidenti avevo perso di vista il thread.. ho provato nuovamente con 
tutti i flag ma ottengo sempre questi kernel panic. ho deciso di dare 
allora una megapulita al computer, riparare i permessi e lanciare 
manualmente i vari script di manutenzione e... la macchina mi si e' 
bloccata dando quello settimanale, inizio a pensare che la formattazione 
sia l'unica soluzione.

 lo farei, hai visto mai;-).
sai come si fa? bisogna editare il codice, o semplicemente basta passare
qualche opzione?
cmq mi rendo conto che il problema e` mio... sempre dovuto alla mancanza
delle dylib.
Quindi non posso 'installare' eric e devo usarlo da ''pythonw eric3'' e
la cosa crea dei problemi...
direi che devo per prima cosa regolarizzare stebenedette qt :)


 l'opzione -qt-gif nel cofigure, e basta, non so che opzioni usi tu?
non ricordo... adesso riprovo.
e per non fargli fare i progetti aggiuntivi? io li ho spostati... c'e`
un modo piu` fine?


 crei eseguibili....
anche questo e` parzialmente falso.
sotto windows crea eseguibili. mai provato, ma si fa, ci sono dei tools
appositi.
sotto unix la definizione di ''eseguibile'' e` un file che puo` essere
eseguito, ovvero che abbia i bit di esecuzione settati e che sia appunto
''eseguibile''. E questo e` possibile in python, in perl, in bash etc
etc...
Sono eseguibili a tutti gli effetti (salvo per una piccolissima finezza
sui sudo, ma e` un'altro discorso).
Non crea eseguibili binari... vero. ma chi se ne frega :))))
1. sotto linux/fbsd/obsd etc etc nessuno si frega di questo, basta che
un programma sia lanciabile da shell (e conseguentemente inseribile nei
menu` delle gui che piu` preferisci).
2. sotto MacOS X puoi creare dei bundle che doppiocliccki e via.
3. sotto MacOS Classic puoi creare delle applet (gia` fatto) che
doppiocliccki e via, oppure delle applicazioni vere e proprie (non
fatto).


 protesti anche avere =)
chi, io?
comunque ho risolto.
il mio problema era
1. avevo un casino di riferimenti incrociati, di source etc, che
facevano perdere tempo
2. ho su gli script di bash_completion, che sono comodi, ma impiegano
tempo ad essere caricati. Ora devo decidere se non caricarli o se
farlo... boh... mi sa che li disabilito.


 un modo piu` fine?
Imho No =)
Whamoo

 2. sotto MacOS X puoi creare dei bundle che doppiocliccki e via.
Sai dirmi come fare? Ci puoi anche mettere le librerie usate vero?
Whamoo




 direi che devo per prima cosa regolarizzare stebenedette qt :)
ho regolarizzato tutto...
ma eric continua a piangere.
booh... mi sa che lo abbandono :)


 qualche opzione?
La seconda che hai detto, ma non ricordo l'opzione, forse -style ...
Alex

 La seconda che hai detto, ma non ricordo l'opzione, forse -style ...
esattamente quella, ty...
cmq anche cambiando stile
QPaintDevice: Must construct a QApplication before a QPaintDevice
da questo errore ogni volta che provo a dirgli di creare un nuovo
documento....


 documento....
Interessante, questo e` un errore "classico" di Qt (eric a parte).
Google da` infatti 162 hits su questa frase (senza virgolette).
Vedi ad es. la spiegazione (in contesto Python) a
http://www.opendocspublishing.com/pyqt/index.lxp?lxpwrap=x2765.htm
Mi chiedo se eric sia proprio colpevole di un erroretto simile...?
Alex

 Mi chiedo se eric sia proprio colpevole di un erroretto simile...?
e` bello strano... voglio dire, in teoria se fosse una cosa cosi` fuori
di testa, dovrebbe sbarellare anche su GNU/Linux, dove invece e`
perfetto...
Non so che pesci pigliare... ora sto compilando il gcc 3.4 e ho la
macchina abbastanza indaffarata, dopodomani ho un esame e ho un mal di
testa incredibile...
Mi buttero` nel debug asap...


 Mi buttero` nel debug asap...
L'esame ha sicuramente la precedenza...!-)
Alex

 
Pero' in teoria sia il compilatore usato sotto linux sia quello usato
sotto Mac e' un gcc, non dovrebbe (almeno in linea teorica) seguire le
stesse convenzioni ? Ovviamente discorso diverso se si compila con
CodeWarrior.
-- 
Ciao
Fabio

 CodeWarrior.
No, gcc (assieme al linker) sta producendo eseguibili di formati assai
diversi e incompatibili (presumibilmente ELF su Linux, Mach-O su Darwin
/ MacOSX), quindi non c'e` ragione di pensare che il codice di start-up
abbia lo stesso comportamento al netto di quello che lo standard
garantisce (cosi` come, a suo tempo, quando Linux transito` dal formato
a.out all'ELF, ma solo i vecchi come me lo ricordano;-).
Il problema dell'esecuzione dei costruttori statici e` una iattura del
C++, purtroppo; puo` causare problemi di ogni tipo, non solo di
compatibilita` ma anche di prestazioni, soprattutto in presenza di
librerie dinamiche (che lo standard C++ con copre proprio).  C'e` una
notevole letteratura in merito, tra l'altro.
Alex

 L'esame ha sicuramente la precedenza...!-)
esame fatto... hai qualche consiglio particolare per affrontare il debug
di un corposo progetto in Python?
Qualche how-to et similia? Oppure io pensavo di usare il 'debugger'
grafico di IDLE per MacOS X (e` diverso da quello per X11 normale e poi
in realta` e` solo il frontend per il debugger di Python, o forse dovrei
dire per i moduli che si occupano del debug... beh, hai capito :) mi
scuso per l'improprieta` di linguaggio). Mi pareva ben fatto etc etc...
scomodo come editor, ma veramente user friendly come frontend per
debugger.


 debugger.
Non voglio certo negarlo -- Anna, ci VIVE, in IDLE, editor e debugger e
tutto.  A me dell'IDE di MacPython piace soprattutto il trucchetto di
"esegui il codice selezionato", e` di un comodo!  Ma non c'entra molto
col debugging...
Alex

 dentro :)
Anch'io.  Conto molto in Luglio-Agosto, dopo la famosa sfida a OSCON fra
Guido van Rossum e Dan Sugalski: sfida alla pura velocita` fra Python e
Parrot con in palio una torta in faccia (il vincitore piazzera` una
torta alla panna in faccia al perdente sul podio dell'Open Source
Convention...).  Comunque vada se ne dovrebbero sentire...!-)
Alex

 dentro :)
io spero di no. non saprei proprio dove collocarmi. alla fine mi
metterei in mezzo e le prenderei da entrambi... :)


 col debugging...
vero... pero` hai ragione e` carino. sfortunatamente l'editor e`
prossimo all'inutilizzabile, quindi alla fine vado di vim e basta... ;)


 Convention...)
rotfl... dovra` essere spettacolare.
piuttosto mi chiedo se Parrot sara` pronto e sufficientemente maturo in
tempo.
comunque a me risulterebbe che pure tu hai un passato (remoto?) da
Perlista... confermi?


 Perlista... confermi?
Confermo, come (si licet parva componere magnis...) Agostino una
gioventu` da spensierato peccatore, Paolo (Saul) una da persecutore di
cristiani, Mussolini una gioventu` da socialista di spicco, ... Non sono
poi cosi` rare queste conversioni...!-)
Alex

 Vabbe', ma allora c'e' speranza anche per sembrolacarta :)
Mi dicono dalla regia che e` l'ultima a morire...
Alex

 Vabbe', ma allora c'e' speranza anche per sembrolacarta :)
Detesto l'innamoramento per le tecnologie.
Le tecnologie (i linguaggi, in questo caso) sono strumenti,
l'intelligenza non sta nel preferirne uno ma nell'usare il piu` comodo
per il problema che si affronta. Passo allegramente e tranquillamente da
Perl ad AppleScript a seconda di quel che devo fare, non di quel che
preferisco. Il Perl lo uso per via delle regex, e per quelle continuero`
ad usarlo per quanto i vari PHP e Python tentino di scimmiottarlo.
-- 
Splendente in eta` acerba di passione
Rosso fiammante
Ma senza eta` matura
Marcia impostura