Newsgroup: it.comp.macintosh
Titolo: g++3 ingordo?

Salve,
torno sulla questione dei compilatori che creano files grossi in Mac OS
X:
con un file C++ ciamondo.cpp di 6 righe:
g++ ciaomondo.cpp -o ciamondo
crea un file circa 6 volte più grande di 
g++2 ciaomondo.cpp -o ciaomondo2
-rw-r--r--  1   salvo  admin    136B  2 Set 21:44 ciamondo.cpp
-rwxr-xr-x  1 salvo  admin    652K  2 Set 21:44 ciaomondo
-rwxr-xr-x  1 salvo  admin    119K  2 Set 21:44 ciaomondo2
siccome g++ è un link a g++3.3 cosa debbo dedurre, che 3.3 ha problemi e
g++2 compila in modo più efficiente?
O è normale che i files siano più grandi?
Ma può un piccolo file che su Linux compilato è di pochi kb diventare
qui 652 kb?
Per completezza, il compilatore gpc per Pascal in Fink ha lo stesso
difetto di g++, mentre il gcc-3.3 per C è efficiente.
ciao,
Salvo
-- 
#!/usr/bin/perl
print "NeXT tip => /me == (~§alvomi©~ @ddress) - (Alfa kai Omega) \n";

 qui 652 kb?
Si, se gli linkano un tot di cose che altrove non e` necessario linkare.
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/

 Si, se gli linkano un tot di cose che altrove non e` necessario linkare.
Vorrei capirci qualcosa :)
PS, solite stranezze di Zuppa: sto rispondendo alla tua risposta al mio
post iniziale, ma questo qui ...non c'č, č grigio. Boh... :)
ciao,
salvo

 Linka meno roba. Strippa ciaomondo2 e vediamo quanto diventa.
Fra le altre varie cose, mi sa che su GNU/Linux di default spara
libstd++ come shared lib, su mac il gcc 3.3 invece la linka
staticamente.
-- 
RiK0
Non credo negli schemi non vincenti.

 g++2 compila in modo più efficiente?
Affatto. gcc 2 e` molto piu` indietro del 3.3, sia come ottimizzazione
(anzi come ottimizzazione e` abissalmente indietro) sia come supporto
allo standard.
Semplicemente il gcc 3.3 non e` in grado di usare le librerie condivise
c++ e lavora in statico. Il 2.95 se ricordo bene lo faceva :))
Comunque puoi andare di debugger e fare tante magiche scoperte!
Comunque il 3.4 gestisce le librerie dinamiche C++ e anchhe il 3.1,
afaik.


 afaik.
Su Mac non c'è ancora?
ciao,
salvo

 Su Mac non c'č ancora?
Certo che si. gcc gestisce le shared da tanto, e` sotto mac che il 3.3
non lo fa. Ma te lo devi compilare a manina.
E a me aveva fatto casino con il prebinding. Riko dice aspettate e apple
vi accontentera`!


 vi accontentera`!
/me aspetta che mamma Apple magnificamente doni suo gcc4 to us :))
ciao,
salvo

 /me aspetta che mamma Apple magnificamente doni suo gcc4 to us :))
3.5 sara` con Tiger, dicono :))


 Cosa si perde dopo strip a ?
Le informazioni necessarie per il debugging. Dopo lo strip niente
debugging simbolico, solo a livello di assembler.


 vi accontentera`!
Ovvero ?


 3.5 sara` con Tiger, dicono :))
capisco :)
ma la Tigre ancora ...dorme ;-)
ciao
-- 
sm

 debugging simbolico, solo a livello di assembler.
ok, allora dopo che si è (per quanto possibile) *abbastanza sicuri* che
il programma funzioni si può strippare.
ciao,
salvo

 writes:


Si. Casomai ricompili. Sotto Cygwin strip fa disastri.


 Ovvero ?
Nella prossima versione dei developer's tools ci sara` il gcc 3.5
Il punto e` che non ho idea di come andrebbe patchato il 3.4 'a mano'
per aggiungerci le sciccherie che ci ha messo Apple (nessuna sciccheria,
semplicemente non se funzionerebbe come compilatore per i progetti di
xcode, cocoa etc etc...)
