Rosetta, l'incontentabile

Casso, c'ho X-Chat che è PPC, e per usarlo Rosetta mi ciuccia quantità di ram industriali... sul sito, sarò io, ma non ho trovato i sorgenti. Ora, sapendo chi appare nella schermata di about, mi chiedevo se era possibile avere qualche aiutino... non voglio un UB, mi basta una compilazione intel, nel caso mi riuscisse di trovare i sorgenti basta una botta di make?
Grassie.

Fattelo preparare UB da Camillo.

Così sarebbe meglio, ma volevo fare in modo da dare meno disturbo possibile... insomma, se basta un link ed un semplice comado per per compilare, penso sia più comodo se faccio io.... se invece si tratta di una cosa particolare, è evidente che per aiutarmi a compilare si perde più tempo che col classico "chi fa da se fa per tre".
Comunque attendo fiducioso una risposta :)

chiedi a leo, lo sa.

Oppure cerca da solo, la prossima volta farai prima di sicuro.

Io so dove stanno i sorgenti. Il problema è che non ho capito una cippa di tutta la storiella del CVS. Fink (con Fink Commander)? Certo, fatto ed installato (senza ricompilare) ed il risultto è che l'unico modo è scrivere xchat nel terminale, per avere...
~ alexthestampede$ xchat

(xchat:9079): Gtk-WARNING **: cannot open display:
Mac-Mini-Core-Solo:~ alexthestampede$
e basta. Non proprio quello che speravo.
Se provassi ad installare da codice sorgente dovrebbe compilare tutto, dipendenze assurde incluse? Non mi fa lo scherzetto di amarok che cerca di compilarsi anche Gnome e Kde, vero?

Casso, 20 minuti che scarica sorgenti. Non butta bene, soprattutto dato che sembrerebbe essere solo a 3/4 del download... temo per la compilazione.

Ecchime qua. Dunque, è un pezzo che non metto le mani su XCA (mancanza di tempo); l'ultima volta non c'era ancora una build per Intel, e non è che bastasse ricompilare, però probabilmente Steve ci ha lavorato nel frattempo. Per il CVS segui le istruzioni di Sourceforge:

cvs -d:pserver:anonymous@xchataqua.cvs.sourceforge.net:/cvsroot/xchataqua login

cvs -z3 -d:pserver:anonymous@xchataqua.cvs.sourceforge.net:/cvsroot/xchataqua co -P xchat

Fammi sapere come va la compilazione.

Nel frattempo, per ridurre il consumo di RAM, prova a togliere tutti i plugin che non usi. Il set di default carica un bel po' di librerie.

Fra l'altro, non ho letto la documentazione di Rosetta, ma sapendo che non supporta il caricamento di plugin con architettura diversa da quella dell'applicazione host, presumo che lo stesso valga anche per le librerie; quindi i plugin di XCA ti fanno caricare le versioni PPC di perl, python, ruby e tcl, e quindi le pagine di memoria di quelle librerie non possono essere condivise con altre applicazioni che le abbiano caricate in versione Intel, col risultato di occupare ancora più RAM.

Ahhh, ecco perchè era *così* pesante. Non era Opera... non Adium... un pochino iTunes, e tanto ma tanto i plug in di Xchat.
Ora provo a fare un bel make (dopo i due comandi che ho già dato :) ) e vediamo se va tutto liscio.

Edit:
Nigga stole my GLIB...
make dice che non c'è il makefile, però con un ./configure ottengo, dopo alcuni macinamenti: checking for pkg-config... /sw/bin/pkg-config
checking for GLIB - version >= 2.0.3... no
*** Could not run GLIB test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GLIB is incorrectly installed.
configure: error: "Cannot find glib"
Mac-Mini-Core-Solo:~/xchat alexthestampede$ sudo make
make: *** No targets specified and no makefile found. Stop.
Mac-Mini-Core-Solo:~/xchat alexthestampede$

:-|

Se scarichi il sorgente da CVS, devi partire eseguendo ./autogen.sh. Di glib forse hai una versione vecchia, oppure è cannata l'installazione di pkg-config (facile).

./autogen.sh si è offeso anche meglio.
$ ./autogen.sh
searching for GNU gettext intl directory...
-> /usr/share/gettext/intl... no
-> /usr/local/share/gettext/intl... no
-> /opt/share/gettext/intl... no
-> /usr/gettext/intl... no
-> /usr/local/gettext/intl... no
-> /opt/gettext/intl... no
-> /usr/gnu/share/gettext/intl... no
-> /opt/local/gettext/intl... no
-> /opt/local/share/gettext/intl... no
ERROR: Cannot find gettext/intl directory.
ERROR: Install GNU gettext in /usr or /usr/local prefix.

Non è la mia giornata fortunata... GLIB lo aggiorno/installo con Fink?

Sì, puoi usare Fink per glib e gettext. Però devi modificare autogen.sh, a un certo punto c'è una riga fatta così:

dirs="/usr/share /usr/local/share /opt/share /usr /usr/local /opt /usr/gnu/share /opt/local /opt/local/share"

Tu aggiungi la directory corrispondente di Fink, non so se sia /sw/share o che. Altrimenti usa DarwinPorts che installa in opt e va già bene.

Darwin ports però non ha un interfaccia grafica, e rimango senza gettext (e visto l'ordine alfabetico, anche senza glib)

Ora sto installando glib tramite Darwin Ports... sperem.

Guarda che gettext c'è.

Altrimenti scarica il sorgente da GNU e vai di configure/make, io ho fatto così.

No, intendevo che non è una cosa pre installata con DP. Comunque ho avuto occhio ad installare per primo GLIB, si è tirato giù anche gettext :D Vediamo come va a finire.

grrrr
./autogen.sh: line 81: libtoolize: command not found
libtoolize failed, stopping.

E darwin ports non trova nessun libtoolize.
Mi sa che ci mettiamo davvero meno tempo se fai una UB stanotte :-\

cavoli, l'informatica fa veramente cagare eh

Apri il file e sostituisci libtoolize con glibtoolize.


La rottura è che dovrei farmi delle UB anche di tutte le librerie che vengono linkate (glib, gettext etc. etc.). Prima o poi lo farò, ma adesso non ho tempo.


Zitto tu, falso nerd. Non hai neanche raccolto la mia frecciata nerd contro Google Video.

andè?

Brrr. Un bel po' di lavoro.... visto così effettivamete si fa prima ad aiutarmi.

Comunque, modificandolo ottengo
running glibtoolize...
You should update your `aclocal.m4' by running aclocal.
running autoheader...
running automake...
plugins/dbus/Makefile.am:16: Libtool library used but `LIBTOOL' is undefined
plugins/dbus/Makefile.am:16:
plugins/dbus/Makefile.am:16: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
plugins/dbus/Makefile.am:16: to `configure.in' and run `aclocal' and `autoconf' again.
plugins/perl/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined
plugins/perl/Makefile.am:6:
plugins/perl/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
plugins/perl/Makefile.am:6: to `configure.in' and run `aclocal' and `autoconf' again.
plugins/python/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
plugins/python/Makefile.am:5:
plugins/python/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
plugins/python/Makefile.am:5: to `configure.in' and run `aclocal' and `autoconf' again.
plugins/tcl/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined
plugins/tcl/Makefile.am:6:
plugins/tcl/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
plugins/tcl/Makefile.am:6: to `configure.in' and run `aclocal' and `autoconf' again.
src/common/Makefile.am:3: library used but `RANLIB' is undefined
src/common/Makefile.am:3:
src/common/Makefile.am:3: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB'
src/common/Makefile.am:3: to `configure.in' and run `autoconf' again.
automake failed, stopping.

Questa roba mi è alquanto oscura, anche se deduco che quel Makefile.am non gli è piaciuto troppo...

Edit: no cazzo, non gli sono piaciuti svariati file, tutti con lo stesso nome! Culo, eh?

che è, metacat? neanche me n'ero accorto

Allora: fai "which aclocal" e prendi il percorso, mettiamo che sia /sw/bin/aclocal; prendi la parte prima di /bin e aggiungi /share/aclocal, ottenendo ad esempio /sw/share/aclocal; poi fai "export ACLOCAL_PATH=/sw/share/aclocal" (col path ottenuto prima), ed esegui di nuovo autogen.sh.


<nerdery level="extreme">
No. Non so se l'hai notato, ma Google Video a volte ha dei ridicoli docid negativi, come nel link che avevo citato: http://video.google.com/videoplay?docid=-2985216487147417042
La colpa può essere solo di Java, che notoriamente e vergognosamente non ha gli unsigned: quello è un onesto id a 64 bit (probabilmente un hash) che sono costretti a rappresentare come signed per non mandare nel pallone la servlet che c'è dietro. LOL.
</nerdery>

Diabolico.

running glibtoolize...
You should update your `aclocal.m4' by running aclocal.
running autoheader...
running automake...
plugins/dbus/Makefile.am:16: Libtool library used but `LIBTOOL' is undefined
plugins/dbus/Makefile.am:16:
plugins/dbus/Makefile.am:16: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
plugins/dbus/Makefile.am:16: to `configure.in' and run `aclocal' and `autoconf' again.
plugins/perl/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined
plugins/perl/Makefile.am:6:
plugins/perl/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
plugins/perl/Makefile.am:6: to `configure.in' and run `aclocal' and `autoconf' again.
plugins/python/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
plugins/python/Makefile.am:5:
plugins/python/Makefile.am:5: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
plugins/python/Makefile.am:5: to `configure.in' and run `aclocal' and `autoconf' again.
plugins/tcl/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined
plugins/tcl/Makefile.am:6:
plugins/tcl/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
plugins/tcl/Makefile.am:6: to `configure.in' and run `aclocal' and `autoconf' again.
src/common/Makefile.am:3: library used but `RANLIB' is undefined
src/common/Makefile.am:3:
src/common/Makefile.am:3: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB'
src/common/Makefile.am:3: to `configure.in' and run `autoconf' again.
automake failed, stopping.

Il comando di export non ha dato output, ed essendo preciso identico all'esempio, ho fatto un semplice copia e incolla.
Qui mi sa che va modificato un filo il codice sorgente per farlo andare, e l'idea mi piace sempre meno...