gcc40 - schon benutzen?

Fusselbär

Makefile Voyeur
Hallo,


am Freitag, 22.04.2005, habe ich auf Pro-Linux gelesen,
das die Gnu Compiler Collection 4.0.0 freigegeben worden ist.
Unter anderem wurde als Vorteil gegenüber der gcc34 angegeben,
das er bis zu 25 Prozent schneller sein soll, beim compilieren von C++,
und obendrein noch ein Fortran Frontend mit Unterstützung
für Fortran 90 und Fortran 95 hat.

Auf Freshports.org ist der gcc40 aufgeführt.

Jetzt geht mir der gcc40 nicht mehr aus dem Kopf,
compiliere ich doch recht oft,
und sehe auch sehr oft, das gmake aufgerufen wird.

Allerdings schnurrrt mein System rund wie ein Uhrwerk vor sich hin.
Aber neues reizt mich immer. :ugly:

Könnte man den gcc40 schon gut anstelle von gcc34 benutzen?
Es wurde im oben genannten Artikel davon gesprochen,
das es im Unterschied zu früheren Veröffentlichungen
wenige inkompatible Änderungen gäbe.

Und wenn ja,
wie stelle ich das am besten an? :confused:
Oder ist zum jetztigem Zeitpunkt aus Gründen der
Erfolgsausichten beim Compilieren noch davon abzuraten? :zitter:

Vielleicht benutzt auch schon jemand die gcc40 und kann davon berichten?


Gruß, Fusselbär

P.S.:
Ich hoffe, ich habe das richtige Unterforum gewählt,
da die gcc ja meistens für die Anwendungen gebraucht wird.
 
Last edited:
Fusselbär said:
... am Freitag, 22.04.2005, habe ich auf Pro-Linux gelesen,
das die Gnu Compiler Collection 4.0.0 freigegeben worden ist.
...
Auf Freshports.org ist der gcc40 aufgeführt.
...
Jetzt geht mir der gcc40 nicht mehr aus dem Kopf,
compiliere ich doch recht oft,
und sehe auch sehr oft, das gmake aufgerufen wird.

Allerdings schnurrrt mein System rund wie ein Uhrwerk vor sich hin.
Aber neues reizt mich immer. :ugly:

Könnte man den gcc40 schon gut anstelle von gcc34 benutzen?...
Zuvor richte man die üblichen Anflehungen an den Heiligen Backup :cool: und seine ebenso verehrte Frau Restore :D .
Im Zweifel benutzt man beide Compiler gleichzeitig:
Nach Installation des neuen Compilers prüft man, ob dieser den Alten ersetzt hat (meist nicht). Ein Kompilieren eines interessanten Ports mit dem alten Compiler und anschließendes "make package" erlaubt es, dasselbe Paket mit dem neuen Compiler testhalber zu compilieren und sorgenfrei zu installieren. Wenn das Ding Mist gebaut hat, installiert man das alte Paket einfach drüber.

buildworld und buildkernel sind da ein wenig anspruchsvoller: wenn der neue Compiler fehlerhaften Code erzeugt, ist eine alternative boot-Partition zur Reparatur des Systems notwendig.

Gerüstet mit dieser Fallback-Strategie geht jetzt Probieren über Studieren -- auch bei mir zuhause.
 
Hallo Cheasy,

danke für Deine Antwort.

Das bauen der neuen World und des neuen Kernels,
funktioniert das tatsächlich mit der Gnu Compiler Collection? :apaul:
Ich dachte FreeBSD hat da seine eigenen Tools in der World,
und nur für die Sachen,
die mit gmake gebaut werden, wird der gcc benutzt? :confused:

Falls die World oder der Kernel wegen
zu neuer gcc nicht gebaut werden können,
würde ich schon Angst kriegen. :zitter:


Gruß, Fusselbär
 
Wenn ich mich nicht irre, wird beim buildworld ein GCC mit gebaut der dann auch installiert wird, inklusive neuer Header und allem drum und dran.
 
Hallo,

unter
/usr/src/UPDATING
wird der gcc jedenfalls einige male erwähnt,
wenn sich etwas geändert hat, das es zu beachten gibt.

Mein Experimentiermut kühlt gerade ab,
ich hatte gehofft, das die flammneue Gnu Compiler Collection 4.0.0
nur für die Anwendungen, aber nicht für das eigentliche FreeBSD
(World und Kernel) verwendet wird.

Vielleicht ist es doch klüger, darauf zu warten,
das die neue gcc40
vom FreeBSD Project selbst "geadelt" wird,
in dem sie in das System darf.


Gruß, Fusselbär
 
Mal was zur Info: http://gcc.gnu.org/gcc-4.0/changes.html

Hier sind die Änderungen dokumentiert. Ich persönlich wäre äusserst vorsichtig so etwas auf einer wichtigen Maschine und vor allem ohne Backup (Cheasy :D) Auszuprobieren. Es wird unzählige Stellen geben, an denen ports z.B. nicht kompilieren werden, das dauert Monate, bis alles hinreichend geprüft ist... Und mal im Ernst: Was kommt den von den theoretischen 25% Performance-Gewinn in realiter beim Nutzer end of the pipe an? Ich glaube ich bin mittlerweile zu alt um irgendwelchem Compiler-Vodoo von wegen Optimierung auf den Leim zu gehen. Das ein Umstieg auf gcc 4.x erfolgen muss ist zwangsläufig (so man nicht Alternativen nimmt, die aber noch fern sind), aber bitte erst nach reiflicher Testphase...
 
Warum installierst du ihn dir nicht einfach, setzt CC=gcc4 in /etc/make.conf und schaust wo das Uebersetzen als erstes abbricht?

Kann so schwer ja nicht sein.
 
Hallo,

ich habe mir mal die Änderungen bei der gcc40,
durchgelesen.
Danke für den Link Daniel. :)
Da gibt es wohl einiges, woran es schon mal hakeln könnte.
Die FreeBSD Konsole hat, glaube ich kein UTF-8, oder?

Das was MrFixit schreibt, klingt ja verlockend,
so ähnlich habe ich mir das ganz blauäugig vorgestellt.
Aber wenn es auch den Bau von World und Kernel betrifft,
bekomme ich Angst.

Kommt hinzu,
das ich eigentlich noch ziemlich unerfahren bin,
was FreeBSD betrifft.
Also selbst wenn ich einen "Crah Test Dummy" gebe,
könnte ich wahrscheinlich gar nicht perfekt beschreiben, woran es hakt,
damit alle davon profitieren.

Ich glaube ich sollte mindestens eine Nacht darüber schlafen. :)
Das einfachste ist sicherlich abwarten,
bis die gcc40 offiziell in FreeBSD integriert wird.
(Auf Freshports habe ich gerade schon die gcc41 gesehen.)
Die Maschine wäre nur meine eigene zu Hause,
die ich als Desktop mit FreeBSD benutze,
aber ich hänge trotzdem an einem funktionierendem System.
Leide aber an schwerer Versionsgeilheit! :ugly:


Gruß, Fusselbär
 
Hallo,

heute, 3. Mai 2005, ist auf Pro-Linux ein Bericht über Tests mit der GCC 4.0
erschienen, mit ernüchternden Ergebnissen.

Hier der Link zum Bericht auf Pro-Linux:
"GCC 4.0 geprüft"
KDE läßt sich zur Zeit gar nicht mit der GCC 4.0 kompilieren.

Da ich mit dem Gedanken gespielt hatte,
den GCC 4.0 mit FreeBSD schon auszuprobieren,
möchte ich hiermit allen Danken,
die mich vor einem vorschnellen Wechsel bewahrt haben,
weshalb immer noch alles einwandfei läuft. :)


Gruß, Fusselbär
 
Fusselbär said:
Leide aber an schwerer Versionsgeilheit! :ugly:

Hallo Fusselbär,

das kenne ich. Hat mich gerade letztens einen schönen Sonntag gekostet als
ich mal eben unseren Source Server auf den neuesten Stand bringen wollte :rolleyes:

Wie heißt noch der kluge Spruch: Never touch a running system :D

Viele Grüße
Stephan
 
Das mit dem "never touch a running system" gilt ja auch nur für Produktivsysteme ;)

Ansonsten, wer kann schon wiederstehen wenn er ein neues Spielzeug bekommt :D
 
-Nuke- said:
Also Apple hat es nicht abgehalten OS X Tiger mit GCC 4.0 zu kompilieren. ;)

Und was bringt das Ganze bitte sexuell ausser dem Schwanzlängenvergleich bei der benutzten gcc-Version? Du kennst die Antwort bereits... Selbstverständlich muss es eine Weiterentwicklung geben, aber bitte nicht um ihrer selbst Willen. Und was für ein Aufwand das ist bei nahezu 13.000 ports + Kernel + Sonstigem kann sich jeder selber Vorstellen. Das ist keine gute Politik des gcc-Teams in meinen Augen, aber mich fragt ja keiner Gott sei Dank. TenDRA sage ich nur, befreit BSD vom GNU!

Sorry, das musste jetzt raus, viele hier werden Verstehen warum. ;) :)
 
Hey, die Frage war, ob man GCC4.0 schon einsetzen kann.

Dann habe ich gesagt, das Apple es schon macht.

Sollte doch nur ein Beispiel sein... ;)
 
TenDRA für FreeBSD?

Daniel Seuffert said:
[...schnippschnapp...] TenDRA sage ich nur, befreit BSD vom GNU!
Sorry, das musste jetzt raus, viele hier werden Verstehen warum. ;) :)
Schon mit TenDRA experimentiert? Kann man damit Ports compilieren?
P.S: mit gcc4 compilierte Testprogrämmchen laufen mehr oder weniger gut, allerdings haben mich sehr viele Compilerabbrüche davon überzeugt, das gcc4 noch nicht reif genug für meine knappe Freizeit ist.
 
Ports kannst Du damit kompilieren (zumindest sehr viele), Kernel allerdings nicht (zumindest müsste ich nicht wie). Ist aber nur relativ "ungar" das Ganze. Nachdem man sich dort radikalerweise entschlossen hat gleich alles zu Entsorgen, was irgednwie nach GNU reicht wird es noch geraume Weile dauern, bis es soweit ist. Problem ist natürlich auch die zur Verfügung stehende manpower...
 
Back
Top