Login
Newsletter
Werbung

Thema: GCC 3.0 am 15. Juni

63 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von slomo am Di, 15. Mai 2001 um 20:22 #
>>Fehler, die in GCC 2.95.x enthalten waren und absichtlich nicht bereinigt wurden, werden ebenfalls nicht in GCC 3.0 behoben.<<

Kann mir einer dieses Vorgehen erklären?

[
| Versenden | Drucken ]
  • 0
    Von Sascha Mandalka am Di, 15. Mai 2001 um 20:32 #
    Es ergbt fuer mich teilweise Sinn. Vor allem der Kernel-Coder haben teilweise um die GCC-Fehler "herumgebaut" und eine Änderung in GCC 3.0 wurde unter Umständen dazu führen, dass der Kernel nicht mehr stabil läuft. In der Regel sind es auch nur kleine Fehler, die nicht sonderlich ins Gewicht fallen. Die "Bereinigung" dieser würde aber schlimme Folgen in vielen Apps haben. Ich weis, "sauber programmieren". ;-)
    [
    | Versenden | Drucken ]
    0
    Von Anonymous am Di, 15. Mai 2001 um 20:37 #
    Na ja vielleicht sollte man mal die Kernel Teile neu schreiben anstatt Fehler als Features zu deklarieren.

    Linux wird doch immer mehr wie Microsoft !

    [
    | Versenden | Drucken ]
    0
    Von LH am Di, 15. Mai 2001 um 20:40 #
    Das klingt ja grässlich! Als Pascal Programmierer bin ich penibel was sauberen Code angeht, das klingt für mich wie eine Horror Meldung! Naja, deswegen ja auch Kernel hacker ;)

    Anonymous > /dev/null

    [
    | Versenden | Drucken ]
    0
    Von Hütteldorfer am Di, 15. Mai 2001 um 20:54 #
    wos, wos?
    gibts in Pascal vielleicht ander Nullen als in C? Wäre mir neu....

    Ansonsten frag ich mich als Fortran Programmierer ob sich die version 3 des gcc auch positiv auf den g77 auswirkt?
    Zu wünschen wär das sehr....

    [
    | Versenden | Drucken ]
    0
    Von LH am Di, 15. Mai 2001 um 21:08 #
    @ Hütteldorfer

    g77 wird mit gcc kompiliert? Autsch. Schön das Freepascal sich selbst Kompiliert ;)

    Mal so als frage: Was ist verbreiteter, Selbst Kompilierende Kompiler(wie Freepascal) oder Kompiler die durch andere Kompiler erzeugt werden (wie scheinbar g77) ? Was kennt ihr für Beispiele?

    [
    | Versenden | Drucken ]
    0
    Von Anonymous am Di, 15. Mai 2001 um 23:33 #
    @LH
    pascal ist doch was für schüler die programmierung lernen wollen, das hat doch nichts mit dem primären einsatzgebiet der proffessionellen software- entwicklung mit c/c++ zu tun.


    [
    | Versenden | Drucken ]
    0
    Von Hütteldorfer am Di, 15. Mai 2001 um 23:42 #
    @Anonymous: wer erzählt denn so ein schwachfug? Meiner meinung nach is Kylix, wenn es denn gut funzt nicht von der hand zu weisen... jedenfalls immer diese abmeierei... "is für schüler...." können wir das mal sein lassen?

    @LH was meinst du mit kompiler compiliernde Programme a la g77. Es ist da ja net so, dass Fortran code in C übersetzt und dann compiliert wird, das nicht. Aber der g77 is, so weit ich es verstehe, ein aufsatz auf dem GCC, korrigierts mich, falls das nicht stimmt.

    [
    | Versenden | Drucken ]
    0
    Von Fex am Mi, 16. Mai 2001 um 00:00 #
    @ LH

    gcc steht für GNU Compiler Collection, und da ist eben auch g77 ein Teil von. Und jetzt rate mal, womit der, vielleicht besser die gcc, kompiliert wird...

    [
    | Versenden | Drucken ]
    0
    Von MichaelB am Mi, 16. Mai 2001 um 08:18 #
    ##Fehler, die in GCC 2.95.x enthalten waren und absichtlich nicht bereinigt wurden, werden
    ##ebenfalls nicht in GCC 3.0 behoben.

    #Kann mir einer dieses Vorgehen erklären?

    Nein. Nicht wirklich. Ich sehe ein, dass bestehende Programme die für gcc 2.95 geschrieben wurden evtl. mit einer Bereinigung der Fehler Probleme hätten, aber trotzdem hätte ich sie gefixt. Man kann ja dafür ein neuen Kompilerschalter einführen, der den "Kompatibilitätsmodus" abschaltet.
    Aber nur die Fehler zu lassen und gar nix zu tun, finde ich nicht so toll. Bei den nächsten Fehlern macht man es genauso und irgendwann hat man dann ein ganzen Rattenschwanz an Fehlern im Compiler, die man ständig mitschleifen und vorallem kennen muss. Und das kanns nicht sein.

    Gruß
    MichaelB

    [
    | Versenden | Drucken ]
    0
    Von Pandabär am Mi, 16. Mai 2001 um 10:48 #
    Das ist das Problem daß auch RedHat mit dem d GCC-Team hatte.
    RedHat hatte einen GCC 2.96 entwickelt und dadrin einige der Fehler entfernt. Das gefiehl jedoch den GCC-Leuten nicht und sie sagten, RedHat würde inkompatible Compilier erstellen. Und wenn ich mich recht erinnere, dann war die Mehrheit von euch auf der Seite des GCC-Teams.
    Und nun? Nun setzen die GCC-Leute ihre Vorstellungen eines GCC-Compilers durch und lassen die Bugs drin und ihr seit wieder unzufrieden.
    Wäre es also doch besser gewesen wenn RedHats verbesserungen, die im GCC 2.96 stecken in den GCC 3.0 eingeflossen wären?

    Ehrlich gesagt kann ich euch hier manchmal nicht verstehen.

    [
    | Versenden | Drucken ]
    0
    Von MichaelB am Mi, 16. Mai 2001 um 11:56 #
    @Pandabär

    Eine propritäre Kompilerversion wie Redhat sie eigenmächtig herausgebracht hat, ist aber auf jeden Fall der falsche(?) Weg. Das führt nur zu Ärger. Da hätte man sich mit dem gcc-Team halt einigen müssen. Deshalb gefiel mir Redhats Vorgehensweise nicht. Und an Stelle des GCC-Teams hätte ich das so (oder so ähnlich) gelöst, wie ich schon sagte. Compilerschalter rein und fertig. Solche Kompatibily-Schalter gibts doch auch woanders, weil das Problem immer mal wieder auftreten kann. DAS wäre für mich der optimale und tragbare Weg gewesen. Deshalb bin ich mit beiden (GCC-Team und Redhat) unzufrieden. Also kein Widerspruch.

    Gruß
    Michael

    [
    | Versenden | Drucken ]
    0
    Von Spark am Mi, 16. Mai 2001 um 12:53 #
    LH, Pascal ist ja nun nicht gerade eine LowLevel Sprache, da ist sauberes Programmieren noch einfach. Aber sobald es dann auf Hardwareebene geht (und das muss nunmal ein Kernel) sieht die Sache schon anders aus.
    Aber ich freue mich schon auf den ersten in Pascal geschriebenen Kernel. ;)

    Ansonsten an alle Ignoranten: Pascal ist keine Schuelersprache, auch wenn sie dafuer geeignet ist. Pascal ist genausogut geeignet fuer die Anwendungsprogrammierung wie jede andere. Nur eben nicht besonders LowLevel. Wer nur die ueblichen Funktionen braucht, der wird mit (Object)Pascal die selben Ergebnisse erzielen koennen, wie mit C/C++.

    Pascal ist auch eine schoen anzusehende Sprache, allerdings lange nicht so schoen wie Python (wie ich kuerzlich feststellen musste). :)

    [
    | Versenden | Drucken ]
    0
    Von LH am Mi, 16. Mai 2001 um 14:20 #
    >LH, Pascal ist ja nun nicht gerade eine LowLevel Sprache, da ist sauberes Programmieren noch einfach.<

    Jup, das ist klar. Aber 99% der Aufgaben bei der Programmierung die ich mache sind auch nicht LowLevel :)

    >Aber sobald es dann auf Hardwareebene geht (und das muss nunmal ein Kernel) sieht die Sache schon anders aus.<

    Assembler :)

    >Aber ich freue mich schon auf den ersten in Pascal geschriebenen Kernel.<

    Hehe, machbar wärs. Aber wozu? Es kommt ja nicht auf die Sprache an. Wenn die Kernel Programmierer C mögen, dann bitte. Ich hasse es ;)

    >Ansonsten an alle Ignoranten: Pascal ist keine Schuelersprache, auch wenn sie dafuer geeignet ist. Pascal ist genausogut geeignet fuer die Anwendungsprogrammierung wie jede andere. Nur eben nicht besonders LowLevel. Wer nur die ueblichen Funktionen braucht, der wird mit (Object)Pascal die selben Ergebnisse erzielen koennen, wie mit C/C++.<

    Jup, Pascal ist eine Klasse sprache die sich nicht vor C/C++ verstecken braucht. Nur haben viele die hier das maul aufreisen 0 Ahnung von Pascal udn denken dabei noch an Turbo Pascal 1.0 oder soetwas. Leute, aufwachen! Delphi und Freepascal nehmen es mit gcc aber locker auf :)

    >Pascal ist auch eine schoen anzusehende Sprache, allerdings lange nicht so schoen wie Python (wie ich kuerzlich feststellen musste). <

    Python kenne ich nur von gesehenen Quellcode und einigen Anwendungen her. Sah ganz nett aus, aber ich kann ohne begin udn end; nicht leben. Ich brauch das einfach :)

    [
    | Versenden | Drucken ]
    0
    Von Christoph Hellwig am Mi, 16. Mai 2001 um 18:25 #
    @Fex

    gcc (zumindest der C-Compiler-Teil) kann mit praktisch jedem C-Compiler uebersetzt werden - im Gegensatz zu FreePascal oder aehnlichem sind die bootstrapping-Probleme da einfach geringer ....

    [
    | Versenden | Drucken ]
    0
    Von Anonymous am Mi, 16. Mai 2001 um 18:27 #
    Klar wäre das der angenehmste Weg, wenn man einfach eine Option --support-bugs dranhängen würde. Aber dann müssen alle Makefiles umgeschrieben werden für die getricksten Programme. Also führt man einen Switch für den Verzicht auf die Bugs ein und einen für die Bugsimulation, was zunächst Default ist. Nach einer angemessenen Wartezeit (Monate bis Jahre) ändert man den Default-Switch in der Hoffnung, daß inzwischen alle Makefiles, die den Bugsupport brauchen, die Option drinhaben.

    Wir lernen: Fehler wachsen sich in der Softwarebranche seeeehr langsam raus, damit alles kompatibel bleibt. Man Vergleiche einen alten Fehler namens DOS, der sich erst nach geschlagenen 20 Jahren auf einem Betriebssystem, dessen Name mir gerade entfallen ist, herausgewachsen haben wird.

    Gruß, WinStop.

    [
    | Versenden | Drucken ]
    0
    Von MichaelB am Fr, 18. Mai 2001 um 15:06 #
    @Anonymous

    Bei dem Compilerswitches ging es mir um das Prinzip und nicht, wie man das im einzelnen realisiert.
    Und wenn, dann würde ich es nicht über ein Switch wie
    --support-bugs oder ähnlichem machen, ein generellen Switch vorsehen, wo man die Versionsnummer des Kompilers angeben kann. Und dann verhält sich der Kompiler so, wie angegeben (inkl.Bugs). Dann so ein Fall kann ja immer wieder auftreten und so hätte man eine flexible Möglichkeit. Einen solchen Schalter hätte man schon längst mal einbauen können, aber manches ist halt doch nicht bis zu Ende gedacht (ohne die Leistung der Entwickler jetzt abwerten zu wollen).

    Hätte, Wäre, Wenn ist für ein Aussenstehenden sowieso immer leicht zu sagen. Mir ist schon klar, dass sowas nicht immmer vorhersehbar ist und passieren kann.

    Gruß
    MichaelB

    [
    | Versenden | Drucken ]
0
Von Anonymous am Di, 15. Mai 2001 um 20:36 #
Was ist denn so neu am GCC das er ne neue Major Nummber bekommt.

Vielleicht kann er ja dann mit Intels oder Microsofts Compiler mal wieder ein kleines bisschen mithalten.

Zur Zeit sieht es ja ziemlich alt aus mit Performance (sowohl er selber als auch die erzeugten Programme).

Hat eigentlich schon mal jemand ne binaere LCC Distribution fuer Linux gesehen. Ich hab
bis jetzt nur die lcc-win32 gefunden.

[
| Versenden | Drucken ]
  • 0
    Von Dnaiel Molkentin am Di, 15. Mai 2001 um 21:01 #
    >Vielleicht kann er ja dann mit Intels oder Microsofts Compiler mal wieder ein kleines bisschen mithalten.

    Eher unwahrscheinlich. Gerade zur Kompilierzeit ist es so langsam, weil er strukturiert aufgebaut ist und die einzelnen Teile nicht zwecks Optimierung ineinander übergreifen können. Der Aufbau wurde so gewählt, damit der GCC leichter zu portieren ist.

    Was den erzeugten Code angeht -- abwarten und Kaffee trinken. Hoffentlich hat sich was getan,
    aber oftmals helfen ja jetzt schon
    Tricks wie -O6 (zeitweise gefählich, aber -O3 is auch ok) oder (bei C++), --fno-exception (sofern das Program
    ohne Execeptions auskommt, was z.B. für Qt und weite Teile von KDE gilt.

    Gruß,

    Daniel

    [
    | Versenden | Drucken ]
    0
    Von Klaro am Di, 15. Mai 2001 um 21:26 #
    Was bringen die Compileroptimierungen (-O6 -O3) an spuerbaren Geschwindigkeitsvorteil?
    [
    | Versenden | Drucken ]
    0
    Von Sebastian Ude am Di, 15. Mai 2001 um 21:40 #
    Es hält sich in Grenzen, kommt aber auch extrem auf die Software an.

    Durchschnittlich dürfte man von maximal 5% reden können.

    [
    | Versenden | Drucken ]
0
Von Michael am Di, 15. Mai 2001 um 21:30 #
Bin kein Programmierer. Ist gcc im Vergleich zu anderen Kompilern wirklich so langsam, was den erzeugten Code angeht?
[
| Versenden | Drucken ]
  • 0
    Von Norbert am Di, 15. Mai 2001 um 22:02 #
    Kaum. Wir kompilieren in meiner Firma auf Solaris, HP-UX, Aix, Win und verschiedenen Linux-Distributionen. Linux ist da eigentlich am schnellsten, aber ich vermute, das es vor allem am BS selber liegt.
    Der aCC und auch der VC++-Kompiler sind wohl noch ein wenig besser. Vor allem läuft der erzeugte Code langsamer (aber _deutlich_ schneller als unter Windows)
    [
    | Versenden | Drucken ]
    0
    Von Sebastian Ude am Di, 15. Mai 2001 um 22:03 #
    Tja, sieh es mal so:

    Unabhängig davon, ob es so ist, hast du nicht viele Alternativen.

    Hast du schon einmal versucht, mit den zahlreichen mehr oder weniger unbekannten kommerziellen Compiliern die es noch so am Markt gibt eine libc oder einen Kernel zu compilieren ? Probier es erst garnicht !
    Wie oben schon erwähnt wird vorallem im Kernel soviel "black gcc magic" benutzt, dass du das vergessen kannst.

    Andererseits sind doch die meisten User mit der Gesamt(!)-Performance ihres Linux-Systems zufrieden, also sofern ist es wohl eher eine Sache des Prinzips als ein akutes Problem.
    Natürlich sollte man mehr Performance rausholen wo es mehr Performance herauszuholen gibt, aber was Unix angeht sollte das *NIE* zu Lasten der Portabilität passieren.

    Es gibt ja schließlich auch noch den AthlonGCC (www.athlonlinux.org) und den PGCC (http://goof.com/pcg).

    Jetzt kommt mir aber bitte nicht mit dem Gerücht, durch PGCC erstellten Binaries würden andauernd Segfaulten und -O2 wäre Lebensmüde beim diesem Compiler.
    Das ist nämlich heute wirklich ein Gerücht.
    Mag ja sein dass der PGCC mal so schlecht war, aber heute ist er auf jeden Fall brauchbar.

    Die Frage ist allerdings, ob das ganze Compiler-Optimierungs-Spektakel etwas bringt.
    Die 3 - 5 % mehr Performance die du damit rausholst sind in den Augen mancher Leute den Aufwand nicht Wert. Zugegebenermaßen gibt es wirklich bessere und effizientere Möglichkeiten die Gesamtperformance eines (Linux-)-Systems zu steigern.

    [
    | Versenden | Drucken ]
0
Von detlef am Di, 15. Mai 2001 um 22:42 #
Kann mir das mal jemand mit der "Regression" erklären?
Warum macht man sowas?
Kann man vielleicht dann den Kernel nicht mehr kompilieren, weil er diese Fehler "benutzt" oder so???

cu detlef

[
| Versenden | Drucken ]
0
Von Udo am Di, 15. Mai 2001 um 23:27 #
Soll kein Flame werden,aber das ist einer der Gründe warum ich etwas gegen Kompilersprachen habe.
Mann ist immer der Perfection des Kompilers ausgeliefert.
Warum also Nicht mal drüber nachdenken das jedes Betriebsystem das in einer "Hochsprache" enwickelt wurde Fehler haben muss.

Wird ein Kompiler eigendlich heutzutage noch in Assembler geschrieben oder sind dort auch schon Hochsprachen am werk die Fehler einbauen können?
Gruß Udo
für den Assembler mal ein Heiligtum war*g*

[
| Versenden | Drucken ]
  • 0
    Von Sebastian Ude am Di, 15. Mai 2001 um 23:36 #
    Der gcc ist zu 100% in C geschrieben.

    Aber sag mal ... wenn du gegen Compiliersprachen bist ...

    Man ist doch bei interpretierten Sprachen genauso von der Qualität des Interpreters abhängig.

    Wenn du es so siehst solltest du gleich alles in Assembler schreiben :-).

    [
    | Versenden | Drucken ]
    0
    Von Udo am Mi, 16. Mai 2001 um 00:21 #
    Meinte Auch Assembler.
    Zur Amigas zeiten(ja ich war jung und begeistert)
    kahm mir Assembler sehr einfach vor.
    Ich war so verrückt jeden Taktyklus der Befehle abzuwägen.:-)
    Und hatte dort nie verstanden(hat sich geändert) warum jemand C so toll fand,wenn dort doch Performance und Platz verschenkt wird.
    Leider lassen sich große Projekte nicht in reinem sauber programmierenten Assembler realisieren.
    So wird es halt auch immer mehr als nur der Programmiere selbst als Fehlerquelle dazu kommen.
    Wie viel Mhz man heute "nur" bräuchte, wenn Assembler nicht eine aussterbende Sprache wär.
    Es lebe die Verschwendung:-)
    Gruß Udo
    [
    | Versenden | Drucken ]
    0
    Von Ingo am Mi, 16. Mai 2001 um 03:03 #
    Guck dir mal die Quellcodes von IdSoft an. DA hast du noch genug Assembler, denn da wo es heute immernoch nicht genug Rechenleistung gibt programmiert man halt immer noch so.

    Ingo

    [
    | Versenden | Drucken ]
    0
    Von Lars am Mi, 16. Mai 2001 um 08:58 #
    Moin,
    Assembler war auf dem 68k sehr einfach und super im gegensatz zu 6502 (ATARI/C64) aber heutzutage kennt fast niemand mehr die vielen unsauberen tricks, die genutzt werden können um den Code noch das letzte abzuringen. Die C/C++ Compiler nutzen diese Tricks und arbeiten dabei aber auf einer abstrakteren Ebene, die das Programmieren erleichtert. Ohne diese Erleichterungen, würde es heute nicht solche großen Projekte geben. Assembler lohnt wirklich nur noch dort, wo man mittels Tuning Tools (truetime etc.) ein großes Performance-Problem gefunden hat. Für den ganzen Rest reicht C/C++ oder sogar Java völlig aus.
    [
    | Versenden | Drucken ]
    0
    Von Anony Mouse am Mi, 16. Mai 2001 um 08:58 #
    Da Menschen nunmal dazu tendieren ab und zu Fehler zu machen und Programmierer auch Menschen sind, ist es ziemlich egal ob ein Programm in Assembler oder einer Compile- bzw. Interpretersprache geschrieben ist.

    Allerdings wage ich zu bezweifeln, daß Assembler zu weniger Fehler führen würde und außerem wäre das gesamte Linux-System (nicht nur der Kernel, sondern auch X, KDE, Gnome, ...) wenn es in Assembler geschrieben würde, wohl erst in 50 Jahren soweit wie es jetzt ist. Über Portabilität reden wir da mal besser erst garnicht.

    [
    | Versenden | Drucken ]
0
Von Frank Baum am Di, 15. Mai 2001 um 23:36 #
Was ist eigentlich Assembler genau?
[
| Versenden | Drucken ]
  • 0
    Von Sebastian Ude am Di, 15. Mai 2001 um 23:43 #
    Du kannst Assembler als eine Programmiersprache die sehr nah am Maschinencode liegt definieren.

    Assembler ist von daher für Menschen sehr komplex und aufwendig zu programmieren, es wird aber gerne in bestimmten Programmen an einigen Stellen Assembler-Code aus Geschwindigkeitsgründen eingesetzt.

    Dadurch ergibt sich auch, dass Assembler-Programme nicht plattformunabhängig sein können.
    Daher ist es wichtig, in Applikationen die portabel bleiben sollen möglichst nur Assembler-Code einzusetzen falls es unumgänglich ist.

    [
    | Versenden | Drucken ]
    0
    Von Sierk am Mi, 16. Mai 2001 um 13:32 #
    Eine Suche per Suchmaschine Deiner Wahl, Eingabe "Programmiersprachen Assembler" ergibt u.a. folgende weiterführende URLs:

    "www.seereuber.com/progsprachen.htm"

    *Wieseo schluckt diese Formular keine URLs???*

    [
    | Versenden | Drucken ]
0
Von Henry am Mi, 16. Mai 2001 um 00:50 #
Na, dann haben sich wohl hoffentlich endlich die Binbär-Inkompatibilitäten erledigt, die RedHat mit ihrem eigenen gcc (aus dem CVS gebaut) in die Linux-Welt gebracht hat. Es wird wohl aber eine ganze Weile dauern, bis der gcc 3.0 der Standard-Compiler unter Linux ist, der gcc 2.95 ist sehr weit verbreitet, und bis alle Distributoren da nachgezogen haben... Ich hoffe nur, dass das alle einheitlich machen.
[
| Versenden | Drucken ]
  • 0
    Von MichaelB am Mi, 16. Mai 2001 um 08:14 #
    Stimmt. Das was Redhat damals gemacht hat, war nicht besonders schön. Auch wenn es vielleicht Vorteile bringt, so ist soetwas doch ein gewisser Bruch.
    Naja schaun mer mol ...

    Gruß
    MichaelB

    [
    | Versenden | Drucken ]
0
Von lodger am Mi, 16. Mai 2001 um 00:53 #
Also, ich bin skeptisch ob diese Version wirklich hält, was sich viele davon versprechen (ANSI Konformität, Performancesteigerung etc.). Andererseits hoffe ich, dass damit die doch recht kontroverse Haltung von RedHat nun der Vergangenheit angehört und deren Distribution wieder binärkompatibel wird. Wenigstens weitestgehend.

@Anonymous, der wo den Kernel umkrempel will:
Schon mal Interviews mit Torvalds gelesen? Oder mal ein paar Artikel über den neuen Kernel aufgegriffen?! Nee... mekrt man. Denn am Kernel 2.4.x ist vieles vollkommen neu implementiert worden. Also, nicht immer gleich mit dem ersten Posting ins Fettnäpchen treten und dummes Zeug labern...

@LH:
Sieh's ein, LH: wer Linux / UNIX lebt, der ist zwangsläufig C/C++ erfahren. Ist nunmal so. Aber deswegen würd' ich mich hier nicht dissen lassen. Und wer weiß?! Vielleicht lernst Du ja mal ein wenig C und klatscht uns hier 'ne KillerApp um die Ohren?! *grins*

lodger

[
| Versenden | Drucken ]
  • 0
    Von LH am Mi, 16. Mai 2001 um 14:10 #
    Ich mag C einfach nicht, das hat nichts mit können zu tun :)

    Momentan schaue ich mir FreePascal näher an. Wenns mir gefällt (danach siehts momentan aus) klatsch ich euch damit Hammer Anwendungen um die Ohren ;)

    [
    | Versenden | Drucken ]
0
Von Holger am Mi, 16. Mai 2001 um 08:53 #
Hi,

mal ne Frage zur Kernelkompilierung:

Kenne mich nicht so gut mit Compilern aus, aber wenn ich nach meiner make menuconfig ein make dep && make bzImage mache, was für ein Compiler wird dann eigentlich genutzt, ist es der gcc? Bringt es Vorteile, einen anderen Compiler zur Kernelkompilierung zu verwenden?

Danke für jedes Info im Voraus.

@anonymusse: Wäre schön, sich mit Namen zu melden - auf Briefe, die ich versende, kommt auch mein Absender.

Nix für ungut und beste Grüße,
Holger

[
| Versenden | Drucken ]
  • 0
    Von MoppyDig am Mi, 16. Mai 2001 um 09:22 #
    jepps, da wird ger gcc benutzt :)
    Wie willst Du einen anderen compiler verwenden? da musste erstmal die makefiles umschreiben (und den kernel). ;)
    [
    | Versenden | Drucken ]
    0
    Von Hüttldorfer am Mi, 16. Mai 2001 um 11:47 #
    @Moppy Dig: ja leider. Strengenommen ärgerlich. Aber das muss man wohl (noch) in kauf nehmen, wenn man die vorteile welche die universalsprache C gegenüber z.b. pascal bietet, nutzt.

    Meine Fortran programme kann ich nach minimalen änderungen an den makefiles praktisch auf jeder plattform innerhalb von ganz kurz übersetzen, da is standard 77 halt glasklar...


    Aber C is halt wie Englisch: weit verbreitet, sehr anpassungsfähig, modern und man kann alles damit ausdrücken ... aber leider versteht ein Amerikaner einen Briten nicht genau...

    *seufz*

    [
    | Versenden | Drucken ]
    0
    Von slomo am Mi, 16. Mai 2001 um 16:35 #
    @Holger

    Kannst es vergessen! Auch C Compiler die den neuesten Standards entsprechen haben mit dem dreckigen Kernelcode nicht fertig.

    [
    | Versenden | Drucken ]
    0
    Von Arnonymous am Mi, 16. Mai 2001 um 16:37 #
    Wolltest wohl sagen: "werden nicht fertig". Aber wir wissen schon was du meinst.
    [
    | Versenden | Drucken ]
    0
    Von Anonymous am Mi, 16. Mai 2001 um 17:56 #
    @Moppy Dig: ja leider. Strengenommen ärgerlich. Aber das muss man wohl (noch) in kauf nehmen, wenn man die vorteile welche die universalsprache C gegenüber z.b. pascal bietet, nutzt.

    Meine Fortran programme kann ich nach minimalen änderungen an den makefiles praktisch auf jeder plattform innerhalb von ganz kurz übersetzen, da is standard 77 halt glasklar...


    Aber C is halt wie Englisch: weit verbreitet, sehr anpassungsfähig, modern und man kann alles damit ausdrücken ... aber leider versteht ein Amerikaner einen Briten nicht genau...


    *seufz*

    Ein Deutscher versteht einen Schweizer auch nicht immer. Liegt am Akzent, beide Beispiele.

    [
    | Versenden | Drucken ]
0
Von Anonymous2 am Mi, 16. Mai 2001 um 09:27 #
> Fehler, die in GCC 2.95.x enthalten waren und absichtlich nicht bereinigt wurden, werden ebenfalls nicht in GCC 3.0 behoben.

AUTSCH !!!

Vielleicht hat man die Fehler absichtlich dringelassen, damit man nicht kompatibel zum gcc 2.96-rothut werden muss, der die Bugs wohl nicht mehr hat ;-)

Alles in allem erinnert mich das gcc-Projekt immer mehr an den Umstieg von Win95 auf Win98... viele Leute benutzen heute noch Win95 mit diversen Patches, weil's einfach stabiler läuft, schneller ist und nix kostet. Ok, gcc kost' auch nix, außer meine Arbeitszeit, wenn ich mich mit den ganzen Bugs rumärgern muß. Also, back to egcs 1.2 oder so ?

Kann mir mal jemand *neutral* und *objektiv* sagen, was ein Entwickler unter Linux jetzt machen soll ? Buggy gcc 3.0 nehmen oder infamous gcc 2.96-xyz ? Sind die jetzt wieder binär kompatibel oder wird es weiter 2 Linien geben ?

*ein überaus genervter Entwickler*

X

[
| Versenden | Drucken ]
  • 0
    Von Ozzy Osborn am Mi, 16. Mai 2001 um 11:06 #
    Also ich als RedHat-Fan, der auch gerne ausgereifte Software benutzen will, würde mich jedenfalls freuen, wenn RedHat auch einen GCC 3.0 ohne Bugs rausbringen würde.
    Ich kann es sowiso nicht verstehen, daß die Bugs drinbleiben, denn Binärkompatibel sind die Bibliotheken GCC 2.x und GCC 3.x ohnehin nicht - genauso wie libc5 und glibc/libc6 inkompatibel waren.

    Und wenn man einmal schmerzhaft feststellen mußte, wie inkomatibel Microsofts Visual C++ zum C/C++-Standard ist und wie viele Programme, die auf anderen Systemen laufen und sich unter Windows mit dem C++-Builder erstellen lassen, jedoch nicht mit dem Visual C++ Schrott sich programmieren läßt, der wünscht sich, daß alle C/C++-Compiler standardisiert sind.

    Vielleicht sollte ich noch erwähnen, daß es schon oft genug vor kam, daß Programme, die auf bestimmten Unixen laufen, sich auf Linux nicht kompilieren lassen - wegen dieser Bugs!
    (hat schon so manchen zur Verzweiflung getrieben).

    Ozzy

    [
    | Versenden | Drucken ]
    0
    Von Spark am Mi, 16. Mai 2001 um 12:59 #
    GCC ist eine Bibliothek?
    [
    | Versenden | Drucken ]
    0
    Von Ozzy Osborn am Mi, 16. Mai 2001 um 14:35 #
    @ Spark:

    Nein Du Witzbold. :-)

    Aber wenn es eine neue Version des GCC gibt, dann kommt automatisch auch eine neue glibc-Bibliothek hinzu. Der C/C++-Compiler und seine ANSI-C/C++-Bibliotheken bilden nun einmal eine Einheit.

    Ozzy

    [
    | Versenden | Drucken ]
    0
    Von Royal am Do, 17. Mai 2001 um 18:48 #
    Ich lerne C++ aus dem Stroustroup (stimmt der Name so?). Mit dem alten gcc konnte ich sowas wie std::numeric_limits::max()
    nicht komplieren (aus ).
    Ich hab nicht alzuviel Ahnung, aber geht das jetzt mit dem 3.0?
    [
    | Versenden | Drucken ]
    0
    Von Royal am Do, 17. Mai 2001 um 18:48 #
    Ich lerne C++ aus dem Stroustroup (stimmt der Name so?). Mit dem alten gcc konnte ich sowas wie std::numeric_limits::max()
    nicht komplieren (aus ).
    Ich hab nicht alzuviel Ahnung, aber geht das jetzt mit dem 3.0?
    [
    | Versenden | Drucken ]
    0
    Von Royal am Do, 17. Mai 2001 um 18:51 #
    Ups, hab zweimal auf Senden gedrückt.
    Ignoriert das und das dadrüber einfach
    [
    | Versenden | Drucken ]
0
Von W@lf am Mi, 16. Mai 2001 um 10:51 #
>Kann mir mal jemand *neutral* und *objektiv* sagen, was ein Entwickler unter Linux jetzt machen soll ?

Ganz einfach:
- für bestehenden Projekte gcc2.95.x
- für neue könnte man den gcc3.x heranziehen

Gruß
W@lf

[
| Versenden | Drucken ]
0
Von roots am Mi, 16. Mai 2001 um 11:58 #
Wenn irgendjemand diese besagten Fehler im gcc kommentiert, dann bitte nur jemand der auch programmiert und was davon versteht.

ansonsten gilt wie immer bei freier software "wenn einem etwas nicht passt, hat man das recht es selber besser zu programmieren" :)

Mfg

[
| Versenden | Drucken ]
  • 0
    Von ex-Anonymous am Mi, 16. Mai 2001 um 19:37 #
    Das hat Rot Hut gemacht. Du kennst die Reaktionen.

    Naja. Fehler hin, Fehler her. Hauptsache das Teil produziert unter Alpha mal nen vernünftigen Code. Sonst bleibt doch nur der 2.96, den auch SuSE AXP benutzen wird, weil sonst z.B. KDE2 nicht annähernd sauber übersetzt.

    Und das trifft auch mich als nicht Programmierer - und das kann auch ich ohne Ahnung von C hier lokal nachvollziehen.

    [
    | Versenden | Drucken ]
0
Von Heiko am Mi, 16. Mai 2001 um 12:03 #
Kann mir das einer beantworten: Der Mozilla 0.9 ist unter Linux bei schwächeren Prozessoren extrem langsamer als unter Windows. Ich habe gelesen, dass dies auch am gcc liegen soll und man dies mit Optionen wie -O3 und -O6 beheben kann. Allerdings sei dies riskant.
Ich verstehe überhaupt nichts mehr. Vor allem, da weiter oben steht, die optione würden nur ca. 5% bringen. Der Windows Mozilla ist aber mindestens doppelt so schnell.
Wei? jamand Rat?
[
| Versenden | Drucken ]
  • 0
    Von Spark am Mi, 16. Mai 2001 um 12:56 #
    Nun, ich bezweifle eigentlich, dass das hauptsaechlich am Compiler liegt... Wer hat denn das gesagt? Eine kleine Rolle spielen solche Optionen natuerlich. Bei grossen Projekten auch sicher mehr, als bei kleinen.
    Bei Mozilla sind aber auch andere Dinge in der Linux Version sehr unterschiedlich.
    Wusstet ihr z.B., dass Mozilla in der Gtk Version allen ernstes auch die Gtk Themes verwendet? Das heisst, bei einem aufwendigen Pixmap Theme, wird zuerst das Gtk Pixmap gezeichnet und dann der Mozilla Theme darueber. Halleluja! :)
    [
    | Versenden | Drucken ]
    0
    Von Anonymous am Mi, 16. Mai 2001 um 13:36 #
    Typisches GTK gehacke halt.
    [
    | Versenden | Drucken ]
    0
    Von greg am Mi, 16. Mai 2001 um 18:45 #
    das mit den pixmap-themes its mir auch aufgefallen undq seitdembenutz oich sie nicht mehr. Naja, wie siehts denn mit dem qt oder xlib-mozilla uas, taugt der was ?
    [
    | Versenden | Drucken ]
0
Von hakman am Mi, 16. Mai 2001 um 14:57 #
Es gibt doch einen C-Standard.
An dem sollte sich jeder Compiler
messen lassen.
Auf alte "Drumrumprogrammiererei" Rücksicht
zu nehmen ist doch Quatsch. Die Bugs muessen
raus!
Da schleppen wir sonst immer die Altlasten mit.
Lieber gibt es für eine Übergangszeit
einen "Kernel-Compiler" bis der Kernel-Code
mit dem GCC 3.0 stabile binaries erzeugt.

Besser jetzt mehr Arbeit und dafür in den
nächsten Jahren weniger Stress...

Cool wäre es sowieso, wenn sich der Kernel
mit jedem beliebigen C-Compiler kompilieren
lassen würde der dem Standard genügt...

hakman

[
| Versenden | Drucken ]
0
Von void am Mi, 16. Mai 2001 um 15:16 #
Die "Regressions"-Strategie ist nicht
besonders förderlich - eher eine Zeitbombe.

Sauberer Compiler & sauberer Anwendungscode:
So muss die Devise lauten.

Auch wenn am Anfang einige Apps nicht laufen.

Mädels & Jungs, wir müssen nach vorne schauen.

[
| Versenden | Drucken ]
  • 0
    Von void* gcc() am Mi, 16. Mai 2001 um 20:45 #
    so wird das jeder halbwegs vernünftig denkende mensch sehen. schade das man jetzt auch unter linux den windows-weg einschlägt :(
    [
    | Versenden | Drucken ]
    0
    Von heckpart am So, 20. Mai 2001 um 11:02 #
    *heul*
    kann ja nichmal zu OS10 von Mac wechseln weil das jetzt auch auf Linux basis läuft... oder hab ich da was falsch verstanden... ?
    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung