Sie könnten es sich wirklich einmal früher überlegen. Die Idee eines milden Übergangs hat hier eine Katastrophe verursacht. (2.95/3.0, 3.0/3.1, 3.1/3.2, ...)
Hi, imho ist es nur eine Binäre-inkompatibilität und nicht wie zwischen 2.95 und 3.0 auch ein source-Problem, was nichts anderes bedeutet, als daß man diesmal nicht mehr machen muß, als neu zu kompilieren.. und dies kann man ja gemütlich im Hintergrund laufen lassen.
Wobei die Frage offen bleibt, warum Du für ein laufendes System den Compiler geändert hast ? Ich meine, für quellbasierte Distributionen spielt eine neue ABI keine große Rolle, und bei Binärdistributionen sollte man den verwenden, den der Distributor mitgeliefert hat. Wenn der innere Zwang besteht, immer das Neueste benutzen zu müssen, sollte man vielleicht doch mal eine quellbasierte Distribution probieren. Ansonsten, für Intel ist der 2.95 kein schlechter (oder: ein ausreichend guter) Compiler. Rückwärtskompatibilität sollte nie "dem Fortschritt(tm)" im Wege stehen - wozu haben wir die Quellen ? Nutzen wir sie. Zu umständlich ? Die "alte" Software ist jetzt ja nicht automatisch schlecht.
Du hast recht, für Intel ist der gcc2.95 "ausreichend", da aber die mehrzahl der z.Zt. in Heimrechnern verbauten CPUs ein AMD Athlon/Duron ist sieht die sache anders aus! Der 2.95 ist dafür höchstens "gerade noch ausreichend, eher mangelhaft" und der icc ist auch nur bedingt eine alternative... Und das Problem mit quellbasierten Distributionen: Gelegentlich ist man ja auch mal gezwungen ein Programm zu nützen, das man NICHT im source hat ... und dann gehen die Probleme los, es sei denn das Teil ist 100% statisch gelinkt (und dementsprechend groß und speicherfressend)
Völliger Blödsinn, Du scheinst mir dem "Optimierungshype" ein wenig zu sehr aufgesessen. Nicht, das ein aktueller gcc Mit Athlon Optimierungen nicht schnelleren Code erzeugt, aber die Geschwindigkeitzuwachs wird doch gerne maßlos überschätzt. Klar ist jeder Prozentpunkt Performance nett, aber nicht so kritisch, das eine Aktualisierung ein _muß_ ist. Außer evtl. fürs Ego: "Was Du nutzt einen alten, lahmen gcc ? Was bist Du denn für ein lamer ?". Mehr ist dazu nicht.
Weiterhin sollte auf Software, die generell nicht im Quellcode vorliegt, keine Rücksicht genommen werden. Die ist meistens eh nur für Intel und dann vermutlich nur ein paar ausgewählt Distributionen. Plus "unfrei".
Wenn Du sie unbedingt brauchst, wie z.B. im Serverumfeld oder bei Deiner "gewarezten" Maya Version, dann tut es ein "altes" System auch. Scheint einigen schwer zu fallen, nicht alles und sofot haben zu können.
Beim GCC hat man keine Wahl. Außerdem ist die Umkehrung deine Aussage ("Was gegen die diet libc linkt taugt.") falsch. OpenSSL lässt sich gegen die diet libc linken. Heißt das OpenSSL taugt. Nein. Es saugt. Und wie.
eigentlich kannst du dich doch erstmal beruhigt zurücklehnen; den compiler 3.1 hast du drauf und ziehst ja IMMER nur die quellen und compilierst dann... von daher könnte es dir egal sein, ausser du möchtest unbedingt gcc 3.1.1 haben; dann dürftest du dein system von vorn beginnen btw hab meins gerade auf gcc 2.96 (gentoo 1.2) gebastelt.
Von Andreas Cordes am Mo, 29. Juli 2002 um 07:49 #
Moin moin ! Ich hoffe mit der Final vom GCC3.1.1 kann ich endlich "transcode" anständig kompilieren.... Beim Export ins MPEG-Format hängt das Programm und gibt eine Critical-Section nicht mehr frei, allerdings nur beim Video-Export ins MPEG, sonst nicht.
Beim 2.95'er hat es noch ganz ordentlich funktioniert ... Deshalb denke ich, dass es am GCC liegt.
Hatte schon eine Beta vom GCC3.1.1 drauf und da hatte ich zumindest kein SegFault mehr, was beim GCC3.1 noch der Fall war, oder war es GCC3.0.4. ?
Was mich am meisten an dieser Inkompatiblität stört, ist dass es keine Information gibt, ob der gcc und der icc (= Intel C Compiler) irgendwann man ein kompatibles ABI entwickeln. Von mir aus kann das GCC Team ihr C++ ABI so oft ändern wie sie Lust haben, nur wäre von mir ein ganz großer Feature Request eine C++ ABI komptatibilität mit dem icc.
Ich verspreche mir davon unter anderem ein hinreichend schnelles KDE.
Hallo, könnte mal bitte jemand erklähren, was das mit combreloc und objprelink2 auf sich hat? Sollte das nicht ab KDE3 direkt mit dabei sein? Und wo sind die Nachteile -stabilität, usw? Wenn ich das richtig verstanden hab, funktioniert das ja mit allen C++ Programmen.., aber lohnt sich das wirklich? Danke, Thomas
Es lohnt sich. combreloc ist etwas das die neuen binutils mitbringen, objprelink2 ist eine weiter entwicklung von objprelink das z.B. nicht mehr extra aufgerufen werden muß beim bauen (keine Makefiles änderung mehr) da es einen g++ Wrapper mitbringt. Ich hab mir damit Mozilla gebaut mit allen möglichen anderen optimierungen, das Ding ist ca. 3 mal schneller als vorher (rein nach gefühl) ansonsten war Java2 SDK die einzige Software die nicht mit objprelink-2 zurechtkommt. Stabilitäts Probleme konnte ich keine feststellen.
man sollte aber auch die glibc mit -z combreloc (linkerflag) bauen und idealerweise den gcc selbst auch (die libstdc++ gehört zum gcc-build)... auf den entsprechenden projektseiten wird auch abgeraten objprelink2 zu nutzen wenn man bereits combreloc nutzt.
idealerweise läuft es halt doch auf einen neubau des systems hinaus. entweder über gentoo oder lfs. die combination der relokationen hat mit c++ eigentlich wenig zu tun... das laden der module und anpassen der adressen geht generell schneller, bei c++ fällt das nur besonders auf weil hier besonders viele dieser informationen vorhanden sind.
Vergiß objprelink2! Die Zukunft ist eine Version von "prelink", die ihre Infos in /var/cache statt direkt in den Libraries/Programmen abspeichert. Ich habe auf meinem System (SuSE 8 [hat die für prelink nötigen Patches in libelf/glibc/Linux drinnen und auch binutils mit combreloc], Athlon 1.3 GHz, 512MB) den gcc 3.1.1 installiert und damit für Athlon und -O3 optimierte Qt 3.0.4 und KDE CVS kdebase und kdelibs gebaut, anschließend das KDE-Verzeichnis samt benutzter Libraries ge"prelink"t: Ein im Speicher befindliches KDE braucht von kdm bis zum vollständig geladenem Desktop ohne wiederhergestellte Programme jetzt 2 Sekunden und ist damit nicht langsamer als ein installiertes normales Ximian Gnome 1.4.
Was steht denn im Text oben ? Version 3.2 von GCC wird [...] als einzige Änderung gegenüber GCC 3.1.1 eine Änderung des C++ ABIs mit sich bringen. Dies ist eine Änderung des Dateiformats des erzeugten Objektcodes [...] um mit dem Quasi-Standard V3, auf den sich mehrere Compiler-Hersteller geeinigt haben, konform zu sein,
Warum schaust du nicht nach (oder weisst es vielleicht sogar), ob der Intel Compiler den Object-Code im Quasi-Standard V3 erzeugt ? Wenn sich mehrere Compiler-Hersteller auf diesen Standard einigen konnten ist vielleicht auch Intel einer dieser Compiler-Hersteller.
Hat das irgendwer schonmal ausprobiert? Ich fände dies einen großen Durchbruch für Linux/i386. Nix gegen den gcc, er unterstützt immerhin so ziemlich alles was mit 0en und 1en funktioniert, aber einen hochgezüchteten C compiler zu haben freut sicherlich auch die Athlon Benutzer
Die Idee eines milden Übergangs hat hier eine Katastrophe verursacht. (2.95/3.0, 3.0/3.1, 3.1/3.2, ...)
imho ist es nur eine Binäre-inkompatibilität und nicht wie zwischen 2.95 und 3.0 auch ein source-Problem, was nichts anderes bedeutet, als daß man diesmal nicht mehr machen muß, als neu zu kompilieren.. und dies kann man ja gemütlich im Hintergrund laufen lassen.
ciao
Volker
Ich meine, für quellbasierte Distributionen spielt eine neue ABI keine große Rolle, und bei Binärdistributionen sollte man den verwenden, den der Distributor mitgeliefert hat.
Wenn der innere Zwang besteht, immer das Neueste benutzen zu müssen, sollte man vielleicht doch mal eine quellbasierte Distribution probieren.
Ansonsten, für Intel ist der 2.95 kein schlechter (oder: ein ausreichend guter) Compiler.
Rückwärtskompatibilität sollte nie "dem Fortschritt(tm)" im Wege stehen - wozu haben wir die Quellen ? Nutzen wir sie.
Zu umständlich ? Die "alte" Software ist jetzt ja nicht automatisch schlecht.
Und das Problem mit quellbasierten Distributionen: Gelegentlich ist man ja auch mal gezwungen ein Programm zu nützen, das man NICHT im source hat ... und dann gehen die Probleme los, es sei denn das Teil ist 100% statisch gelinkt (und dementsprechend groß und speicherfressend)
Nicht, das ein aktueller gcc Mit Athlon Optimierungen nicht schnelleren Code erzeugt, aber die Geschwindigkeitzuwachs wird doch gerne maßlos überschätzt.
Klar ist jeder Prozentpunkt Performance nett, aber nicht so kritisch, das eine Aktualisierung ein _muß_ ist. Außer evtl. fürs Ego: "Was Du nutzt einen alten, lahmen gcc ? Was bist Du denn für ein lamer ?".
Mehr ist dazu nicht.
Weiterhin sollte auf Software, die generell nicht im Quellcode vorliegt, keine Rücksicht genommen werden. Die ist meistens eh nur für Intel und dann vermutlich nur ein paar ausgewählt Distributionen. Plus "unfrei".
Wenn Du sie unbedingt brauchst, wie z.B. im Serverumfeld oder bei Deiner "gewarezten" Maya Version, dann tut es ein "altes" System auch.
Scheint einigen schwer zu fallen, nicht alles und sofot haben zu können.
cu
slyzer
objdump --full-contents --section=".comment" /opt/kde3/bin/konqueror
Zeigt zumindest bei mir an, dass das ganze mit dem "GCC: (GNU) 2.95.3 20010315" kompiliert wurde.
Hoffentlich gibts dann ne möglichkeit, das einfach zu updaten.
aber es soll ja eh bald der 3.2er kommen
Ich hoffe mit der Final vom GCC3.1.1 kann ich endlich "transcode" anständig kompilieren....
Beim Export ins MPEG-Format hängt das Programm und gibt eine Critical-Section nicht mehr frei, allerdings nur beim Video-Export ins MPEG, sonst nicht.
Beim 2.95'er hat es noch ganz ordentlich funktioniert ... Deshalb denke ich, dass es am GCC liegt.
Hatte schon eine Beta vom GCC3.1.1 drauf und da hatte ich zumindest kein SegFault mehr, was beim GCC3.1 noch der Fall war, oder war es GCC3.0.4. ?
Nun denn, schaun wir mal ....
Bis denn ....
Ich verspreche mir davon unter anderem ein hinreichend schnelles KDE.
könnte mal bitte jemand erklähren, was das mit combreloc und objprelink2 auf sich hat?
Sollte das nicht ab KDE3 direkt mit dabei sein? Und wo sind die Nachteile -stabilität, usw?
Wenn ich das richtig verstanden hab, funktioniert das ja mit allen C++ Programmen.., aber lohnt sich das wirklich?
Danke, Thomas
Es lohnt sich. combreloc ist etwas das die neuen binutils mitbringen, objprelink2 ist eine weiter entwicklung von objprelink das z.B. nicht mehr extra aufgerufen werden muß beim bauen (keine Makefiles änderung mehr) da es einen g++ Wrapper mitbringt. Ich hab mir damit Mozilla gebaut mit allen möglichen anderen optimierungen, das Ding ist ca. 3 mal schneller als vorher (rein nach gefühl) ansonsten war Java2 SDK die einzige Software die nicht mit objprelink-2 zurechtkommt. Stabilitäts Probleme konnte ich keine feststellen.
Mfg jensemann
auf den entsprechenden projektseiten wird auch abgeraten objprelink2 zu nutzen wenn man bereits combreloc nutzt.
idealerweise läuft es halt doch auf einen neubau des systems hinaus. entweder über gentoo oder lfs. die combination der relokationen hat mit c++ eigentlich wenig zu tun... das laden der module und anpassen der adressen geht generell schneller, bei c++ fällt das nur besonders auf weil hier besonders viele dieser informationen vorhanden sind.
Version 3.2 von GCC wird [...] als einzige Änderung gegenüber GCC 3.1.1 eine Änderung des C++ ABIs mit sich bringen. Dies ist eine Änderung des Dateiformats des erzeugten Objektcodes [...] um mit dem Quasi-Standard V3, auf den sich mehrere Compiler-Hersteller geeinigt haben, konform zu sein,
Warum schaust du nicht nach (oder weisst es vielleicht sogar), ob der Intel Compiler den Object-Code im Quasi-Standard V3 erzeugt ?
Wenn sich mehrere Compiler-Hersteller auf diesen Standard einigen konnten ist vielleicht auch Intel einer dieser Compiler-Hersteller.
Also ich hab nun ein wenig rumgeforscht. Laut dem GCC Team wird der neue GCC 3.2 den sogenannten "V3 multi-vendor standard" einhalten.
Auf der Intel Webseite zum icc 6.0 liegt ein Beschreibung im PDF Format die auf Seite 5 dem icc ebenfalls diese Kompatibilität bescheinigt.
Hat das irgendwer schonmal ausprobiert? Ich fände dies einen großen Durchbruch für Linux/i386. Nix gegen den gcc, er unterstützt immerhin so ziemlich alles was mit 0en und 1en funktioniert, aber einen hochgezüchteten C compiler zu haben freut sicherlich auch die Athlon Benutzer