Newsgroup: it.comp.os.linux.software
Titolo: gcc funzionante

Salve,
la copilazione di xsane mi abortisce con il seguente messaggio di errore:
make[1]: Entering directory `/mnt/archive/redhat/BUILD/xsane-0.80/po'
file=./`echo cs | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH no -o $file cs.po
/bin/sh: no: command not found
make[1]: *** [cs.gmo] Error 127
make[1]: Leaving directory `/mnt/archive/redhat/BUILD/xsane-0.80/po'
make: *** [all-recursive] Error 1
Bad exit status from /var/tmp/rpm-tmp.12728 (%build)
a quanto ho capito dovrebbe essere un baco del compilatore.
Attualmente uso:
cc-c++-2.96-0.61mdk
gcc-2.96-0.61mdk
gcc-cpp-2.96-0.61mdk
La versione 2.96 e' cosi' "bacata"? In caso affermativo come mai alcune
distribuzioni (ad es. Mandrake) lo usano per compilare alcuni programmi,
quali vantaggi dovrebbe garantire?
Grazie.

 quali vantaggi dovrebbe garantire?
La 2.96 *non* è bacata. E' la release che viene usata in tutte le
-- 
~Massimiliano ADAMO | Yahoo!Messenger: quetzalco_it | ICQ# 103417788
--------------------------------------------------------------------
".... signori, a voi la cultura, quella con la Q maiuscola"
Gianfranco D'angelo

 La 2.96 *non* è bacata. E' la release che viene usata in tutte le
... e poi? DISTRIBUZIONI?
Bhe' se non e' bacata tanto meglio. Ma allora come mai ho questo errore?
Dopo l'upgrade alle ultime gcc-2.96, DOMANI, della mandrake ti sapro' dire...
Ciao.

 upgrade mi darebbe dei problemi con altri programmi... ecc. ecc.
ecc. ecc. un corno :)
Le librerie che ti richiede il binario te le richiederà anche il sorgente.
Non pensare che il sorgente sia così speciale, rispetto ai binari, al
punto di poter funzionare da funzionare senza librerie :P
p.s. .. conviene andare fuori dai binari?? :)


 uso:
A me sembra invece che l'errore sia la mancanza del programma 'no' (vedi
la riga no: command not found), anche se non ho la piu' pallida idea di
cosa sia.

 p.s. .. conviene andare fuori dai binari?? :)
 
bhe... se continui a fare sempre le stesse identiche cose non imparerai
mai nulla ;-)
Ciao Ciao.

 cosa sia.
mmm... anche io ho visto quella riga ma:
1) non so quale pacchetto contenga questo misterioso no
2)su gogle questo errore trova articoli che parlano di bachi del
compilatore...
ciao.

 tranquillamente con la libreria x,n-1.
Secondo te ha senso quello che hai scritto? Può essere vero che accade e
ti credo ciecamente ma ....
ascolta .... l'installazione e/o compilazione di un pacchetto prevedono
una fase preliminare di check delle dipendenze.
Il check viene eseguito in base a dei criteri che vengono stabiliti dal
"pacchettizzatore".
Nel caso di un sorgente i criteri vengono inseriti nel Makefile.
Nel caso di un RPM sono scritti invece nel file SPEC. Gli altri sistemi
di pacchettizzazione (deb e tarball BSD) non li conosco a fondo.
Se c'è una discrepanza nel check tra binario e sorgente, se la release
del software è la stessa, si tratta certamente di un errore del
pacchettizzazione ... o nel file spec o nel makefile, non è importante
ma in uno dei 2 file c'è qualcosa che non va.
L'unica ecccezione, per cui non si avrebbe un errore, è quella in
cui cui un programma viene con le librerie linkate staticamente.
In questo caso (ovviamente) le librerie non saranno ricercate....
Altro caso assurdo, sarebbe quello in cui il programma ti installa lui
le librerie ... ma non scherziamo, non siamo mica in windows.
RIPETO: serve veramente "uscire dai binari" quando siete ancora all'ABC?
Credete di aver fatto una gran cosa installando un sorgente (che poi
avrete difficoltà a rimuovere)? Tu sai quanti pacchetti sono predisposti
per la procedura "make uninstall"? Non lo sai? Te lo dico io: 1 su 10.
Tu sai che installando sorgenti non hai a disposizione un database dei
pacchetti installati e che i pacchetti che possono essere installati in
un sistema linux possono essere anche 1.000 (leggasi mille)? Credi che
la bravura di un sistemista si misuri dal fatto che usi binari o
sorgenti? ... e poi non mica così difficile installare un sorgente ..
sai?


sorgenti? ... e poi non mica così difficile installare un sorgente ..
Detto da uno che ha appena scritto che i tarball non hanno l'uninstall
e non si riescono a usare perche' se installi troppa roba ti perdi,
qualunque affermazione perde rilievo.
-- 
           ~~ ICQ#: 8761263 ~~ 
http://www.delymyth.net/
 ~~
            E-Mail Addy: DElyMyth [at] delymyth [dot] net
           => FREE! Hardware Anti-Virus!!! - /dev/brain <=
Chi lavora avvelena anche te, digli di smettere - DElyMyth@work

cosa sia.
La shell. Prova a cambiarla in /bin/bash. 
icq 122395780

 qualunque affermazione perde rilievo.
Ci sono situazioni e situazioni. ... pensa ad un CED con tantissime
macchine e prova a pensare cosa succederebbe se su decine di macchine tu
non conosci il sofware installato ... siamo nell'ordine delle migliaia.


non conosci il sofware installato ... siamo nell'ordine delle migliaia.
Se gli admin sono tanto deficienti da non tenersi i makefile (basta
quello per un make uninstall) della roba che installano non e' colpa
mia, io le cose le mantengo ordinate (ti sei mai chiesto a cosa serva
la dir. /usr/src? A metterci i sorgenti della roba che compili, ma Tu
lo sai perche' sai tutto.)
Dubito che rispondero' ancora, alla prossima finisci dritto nell'oblio
dato che vedi solo il tuo bel mondo di RPM binari che hanno le
funzioni che hai sempre desiderato...
Per curiosita', la versione RPM di sylpheed supporta SSL e LDAP?
No perche' quando l'ho messo da rpm su RH non mi pareva proprio li
supportasse, e nemmeno gpg, peccato che a ME servano.
Oddio, e' vero, io sparo palle, sono ignorante e Tu invece sei sicuro
che non ti serviranno mai opzioni non standard.
Beato te che ti accontenti, pero' al tuo posto userei windows.


 accontenti, pero' al tuo posto userei windows.
Se mi piace usare solo i binari, perché proprio windows? C'è Tru64, c'è
Aix, c'è Solaris, c'è Unixware, c'è SCO, c'è Novell, c'è Mac ... ci sono
tutti i sistemi operativi del mondo ... + windows - linux. ... ma in
fondo, anche su linux posso usare i binari, quindi sono contento così.


 Avro' culo io?
Al di la` di dotazioni anatomiche, esiste dell'ottimo software per
gestire i files sparsi creati dalla compilazione diretta dei sorgenti.
Stow ad esempio.
-- 
Questo e'cio'che la musica e'per me: una delle maniere di dire che
l'universo in cui viviamo, che ci e'stato dato, e'grande e bello.
(John Coltrane)
Ciao,Alessandro.
[se vuoi spedirmi un'email, togli il poeta dall'indirizzo]

 punto di poter funzionare da funzionare senza librerie :P
Beh ... in generale é falso. Bisogna vedere caso per caso: un binario é più 
vincolato ad una specifica libreria.
 



Oggettivamente, non c'è nessuna ratio in questa affermazione.
Spiegami cosa vuoi dire .... 
... ah .. qualsiasi cosa vuoi dire, presupponi sempre che un binario,
prima di essere tale, era anche lui un sorgente.


Stow ad esempio.
Metodo artigianale...
mi tengo le dir dei sorgenti nella home (so che andrebbero in /usr/src
ma dato che come root ci entro solo per ricompilare il kernel mi trovo
meglio a tenere quei file dove li scarico :P)
Per le dipendenze c'e' il buon configure che mi s'incazza quando mi
dimentico di leggere i readme, quindi me la cavo egregiamente anche
li'... :)
Per il make uninstall, ieri l'ho usato per downgradare pan (so che non
s'incazzava se davo il make install del vecchio, ma dato che il nuovo
crashava troppo, colta da nevrosi ho dato il make unistall e
reinstallato il vecchio... sara' mai stabile quel programma?)


 reinstallato il vecchio... sara' mai stabile quel programma?)
A naso, direi che gli ci vuole qualche altro mese di sviluppo per diventare
realmente usabile.


realmente usabile.
Argh :(
Comunque riprovo stasera cancellando la .pan come mi hanno risposto
all'altro post... sempre se non reinstallo stasera :)


 prima di essere tale, era anche lui un sorgente.
Prova con questo esempio:
#include <stdio.h>
int main(){ printf("Hello world !"); } 
Compilalo su di una redhat 7.2 e provalo a far girare su di una slackware 
3; poi prova a ricompilarlo su di una slackware 3 . Scoprirai che il 
sorgente é più portabile del binario.
In sostanza: i binari sono vincolati ad una precisa release di libreria in 
maniera stupida; i sorgenti sono vincolati solo alle specifiche: non é 
detto che librerie precedenti a quelle che ho non supportino tali 
specifiche.
Con l'esempio di sopra ti ho dimostrato che IN GENERALE quello che affermi 
tu NON é vero. 

 da pacchettizzazioni (anche stow, non lo dire, l'ho capito :P)
Tranquilla, non sono un estremista stowista. :)


 sorgente é più portabile del binario.
Sempre poca ratio.
Se uso RedHat scarico i binari per RedHat, se uso Debian scarico
i binari per Debian .... e così via. Esistono binari per ogni
distribuzione ed esistono binari compilati per processori specifici ...
esistono anche i sorgenti che si trasformano in binari. Nella mia
macchina ho alcuni src.rpm per PPC compilati per la redhat i386


 per la procedura "make uninstall"? Non lo sai? Te lo dico io: 1 su 10.
su questo ti hanno gia' risposto altri, per fortuna...
Ad ogni modo ti faccio presente che il mio TEMPO e' PREZIOSO e non ho
voglia di stare dietro alle tue fantasie quando posso spenderlo in mondi 
molto piu' piacevoli.
Spero che la discussione sia conclusa. 
Arrivederci.
Antonio.

 macchina ho alcuni src.rpm per PPC compilati per la redh
Io ho sul mio hd dei programmi dos ... che centra ?

 Io ho sul mio hd dei programmi dos ... che centra ?
Beh :)
Gia' che ci siamo, sulla mia macchina ho le libdockapp per OpenBSD
(compilate su Slack :P)...
Me servivano :(
-- 
           ~~ ICQ#: 8761263 ~~ 
http://www.delymyth.net/
 ~~
            E-Mail Addy: DElyMyth [at] delymyth [dot] net
           => FREE! Hardware Anti-Virus!!! - /dev/brain <=
Powered By Slackware 8.0 on Asus L7300G - Kernel 2.4.7 - WMaker 0.70.0

veramente la pena?
"Se non e` uno shell server, per quanto mi riguarda no."
Marco d'Itri

 Ti riporto la tua affermazione a cui io ho risposto con un controesempio.
Noi non ci capiamo perché partiamo da "filosofie" diverse.
La mia filosofia è questa:
Compilare e perdere delle ore appresso a problemi di dipendenze, per me,
equivale a sciupare il  mio tempo ... in quanto ...  Io campo facendo il
sistemista e credo di non essere il solo qui dentro.
Compilando e ricompilando alla fine tutto quello che avrei l'opportunità
d'imparare  sarebbe  qualche  casistica   di  installazione  di  qualche
libreria e di qualche programma ludico.
Io ho sostenuto dei colloqui di lavoro e se da questi è sortito qualcosa
di buone,  credimi, non è perché  gli ho detto "io  so compilare", bensì
perché gli  ho potuto  dire che conoscevo  svariati servizi  sui sistemi
Unix.
Alle fine di tutto:  a compilare ci riesco anch'io (non  è che ci voglia
una gran scienza), ma preferisco usare il mio tempo dedicando a cose più
fruttuose.
Se  cercassi  lavoro  come  programmatore,  allora,  forse  sarebbe  più
importante addentrarsi nel vostro vicolo buio della compilazione.
