Na aber ist es nicht so, dasz gcc 2.96 eben schon mehr als 2.95 aber eben noch nicht 3 (also eine zwischenversion) ist? gegen einen guten cvs snapshot hat ja eh keineR was, aber eine offiziell als "nicht empfohlene" version zu benutzen ist schon etwas komisch. von "technischer neuerung die in kuerze.." kann ja dann wohl keine rede mehr sein. eher schon schaut dasz nach einer (unbeabsichtigten?) fork aus.
Natuerlich hat niemand was dagegen, wenn die Distributoren Vorversionen oder CVS Snapshots auf ihre CDs packen. Aber dann doch bitte als "nice to have" Pakete fuer Experimentierfreudige. RH7 hat einen CVS Snapshot als Defaultcompiler! Damit werden alle RH7 User zu Alphatestern verdammt! Ausserdem halte ich es fuer ziemlich arrogant wenn RH glaubt, sie koennten bestimmen, wann eine Release mit welcher Versionsnummer erscheint. Wann ein Programm fertig ist wissen ja wohl immer noch die Entwickler am besten.
der Vergleich zu Kernel 2.4-testing sowie zu KDE 2.0 hingt ja wohl gewaltig. Bei beiden handelt es sich auch nicht um CVS-Snapshots. Der neue Kernel ist ausdruecklich zu Testen freigegeben, das andere ist ein Release.
Dass mit gcc 2.95.2 keine stabilen Distris zu bauen sind, ist eine Frechheit gegenueber anderen Distributoren. Ob andere Distributoren demnaechst ebenfalls mit CVS-Snapshot-Compilern Distris bauen, wage ich zu bezweifeln.
Von Thoralf Will am Di, 24. Oktober 2000 um 10:17 #
oh, richtig konstruktive kritik. hast du jemals ein redhat-system installiert? - wohl eher nicht. ich habe bereits die beta von rh7 vor einigen wochen getestet und keine wirklich groben fehler entdecken können. wenn die rothüte bei der final nicht alles über den haufen geworfen haben, dürfte die distri durchaus nicht so schlecht sein.
btw: bei uns in der firma vergeht kaum ein tag, an dem ich nicht das gleiche ("...in die haare schmieren...") über die verschiedenen suse-versionen denke die hier auf diversen servern werkeln.
hier geht es nicht um SuSE oder andere, sondern um RH und darum, ob man Distris mit inkompatiblen und selbst von den gcc-Entwicklern nicht unterstuetzten Kompilern gebaut werden und was davon zu halten ist. Ob Dir RH7 ansonsten gefaellt, ist eigentlich ziemlich Banane, und was Du von SuSE haelst sowieso.
BTW: sicher hab ich schon RH installiert, bin also nicht minder genial ...
der gcc ist inkompatibel zu den gcc-vorversion - das war die glibc bei einführung auch.
und für eine distribution ist es enorm wichtig ob sie mir gefällt oder nicht. was hilft mir der schönste compiler und die tollsten bibliotheken, wenn ich mir den kram doch wieder komplett neu bauen muss, weil der aufbau derart verbockt ist, dass ich selbst mit einem dutzend symbolischer links keine vernünftige struktur in das system bekomme.
ich hatte mit keinen komatibilitätsproblemen bei der rh7beta zu kämpfen, die struktur passt und funktioniert. als vergleich habe ich suse herangezogen, weil die ihre configfiles an den unmöglichsten stellen ablegen und die rc.config in meinen augen die unelegateste lösung ist, die man nur finden kann.
nebenbei habe ich noch eine mail von Patrick Spingys mit dem hinweis auf eine seite zur kompatibilität von gcc bekommen. hab sie selbst noch nicht komplett gelesen: http://www.ixsoft.de/gcc296-de.html
die naechste Sufe der gcc Entwicklung ist 3.0. Der RH gcc 2.96 stellt ueberhaupt keine Stufe in der Entwicklung das, ausser der eines beliebigen CVS-Snapshots, der ebenfalls zu 3.0 inkompatibel sein wird. Mit dem Uebergang von glibc5 zu glibc2.0 und 2.1 hat das nichts zu tun. Dass Redhat eigene Schnappsideen als Entwicklungsschritt dieser Kategorie deklariert, ist eine Frechheit.
Von Christoph Hellwig am Di, 24. Oktober 2000 um 14:19 #
@Thoralf Will
Anstatt das ixsoft/RedHat Marketing zu zitieren Frag mal lieber die Entwickler des gcc. Wir können ja eine Wette abschliessen ob der Redhat gcc snapshot und gcc 3.0 C++-Binär-Kompatibel sind ...
Eigentlich ist es sowieso egal, das bisher kaum ein gcc zum vorigen C++-Binär-Kompatibel war und ein großteil der in C++ geschriebenen kommerziellen Software sowieso mit einer eigenen gebundelten libstdc++ kommen. (libstdc++ ist das eigentliche kompatblitaetsproblem, warum die immernoch mit dem gcc gebundelt wird anstatt ein separates packet zu sein ist eine ganz andere Frage ...)
Von Christoph Hellwig am Di, 24. Oktober 2000 um 18:49 #
@Thoralf Will
> es würde mich wundern, wenn der gcc2.96-rh inkompatibler zum gcc3.0 als der aktuelle 2.95.x wäre.
"Inkompatibler" finde ich einen komischen ausdruck: Entweder etwas ist kompatibel, oder es ist nicht. Und der rh Gcc-Snapshot ist zu gcc 2.95.x nicht kompatibel und wird mit grosser Warscheinlichkeit zu gcc 3.0 nicht kompatibel sein.
Das ehr archtiekturell mehr vom gcc 3.0 hat bezweifle ich garnicht.
Das, was mir ein wenig Gedanken macht, ist die Kompatibilitaet der RH RPMs zu anderen Distris. Immerhin ist nicht gerade ein unwesentlicher Teil der RPMs, die man so im iNet findet, fuer RH. So far macht meine Mandrake damit keine Probleme (ist ja nen RH Klon), aber wenn die Teile wirklich nicht mehr binaerkompatibel sind?!?
Naja, mal auf den Ideenreichtum der Franzosen hoffen :)
Von Frank Arnold am Di, 24. Oktober 2000 um 11:05 #
Schon erstaunlich wie sich die RedHat Verkäufer z.B. auch Ixsoft jetzt drehen um allen zu suggerieren "kein problem, bitte kauft es trotzdem...". Sogut wie der aktuelle CVS-Snapshot vom gcc auch sein mag, es ist eben noch kein offizielles stable-release und damit für den Produktionseinsatz nicht zu empfehlen. Diese einfache Logik hat uns bisjetzt davor geschützt ein instabiles und damit kaum benutzbares Linux zu erhalten.
Also Leute, lasst die Finger von dem neuen RedHat! Da die meisten eh nur das update auf XFree4 bzw. KDE2 interessiert, reicht auch der Kauf einer Linux-Zeitungs-CD bzw. der eigene download. Stabilität und Kompatibiliät sollten wichtiger sein, als der "run" auf irgendeine neue Version einer Distribution.
Richtig. Es gibt ja Leute, die im Prinzip ihre RedHat 5.1 oder SuSE 6.0 nach und nach updated haben. Ich finde dieses "oh, neue Version meiner Lieblingsdistri?! Sofort kaufen!" Getue ohnehin nervig. Dann hätten die Leute auch weiterhin Windoze benutzen können. Es geht bei Linux eben *nicht* darum, immer "das neueste" zu haben, sondern darum, ein bestehendes System nach und nach zu erweitern.
Trotzdem ist RedHat nach wie vor eine gute Distri. Und Fehler hat auch SuSE oder ixSoft schon gemacht. Hat beiden nicht geschadet.
Und wer lange genug mit Linux arbeitet, der wird sicherlich in der Lage sein, einen KDE-2.0 tarball oder SRPMS zu kompilieren. Dank RPM oder auto- config ist das ja mittlerweile recht einfach und kommt auch vielgeplagten Admins entgegen.
Wer dennoch ob der vielen Wieder- sprüche in der Linuxwelt "kalte Füße" bekommt, dem sei (wie so oft!) FreeBSD nahegelegt. Dort nimmt man es sogar mit den Sicherheitslücken bestimmter Programme dermaßen ernst, daß z.B. Lynx eine gewisse Zeit nicht als Port verfügbar war, da es den Sicherheitsanforderungen des FreeBSD Teams nicht gerecht wurde. RedHat, SuSE und Co. haben das Paket trotzdem beigefügt und darauf vertraut, daß sich die Anwender die entsprechenden Updates schon von selbst einspielen werden.
Nicht, daß ich jetzt hier einen Flamewar beschwören möchte. Ich bin lediglich der Ansicht, daß es überall etwas zu kritisieren gibt.
Du Quatscher, probiers aus, gcc 2.96 ist ueberhaupt kein Problem, weder mit Kernel 2.4 noch mit irgendwelchen anderen Dingen. Ich selbst bin Debian Entwickler und mich kotzt dieses Rumgehake auf Red Hat von Leuten an die nicht wissen worum es geht sondern nur das von anderen die genausowenig Ahnung haben nachplappern.
Erstens: falls Du mich als "Quatscher" bezeichnet hast: mäßige Deinen Ton. Wenn Du mein Posting gelesen hättest, statt es zu überfliegen, hättest Du gelesen, daß ich RH nach wie vor für eine tolle Distri halte. Und stell' Dir vor, ich setzte sie sogar ein. Was man von Dir als "Debian Entwickler" ja wohl kaum erwarten dürfte...
Und außerdem habe ich weiter unten im Forum ja bereits die Entscheidung von RH für den gcc 2.96 befürwortet.
Also, lieber Anonymous: kein Grund zur Panik...
Und überlasse die Entscheidung, *wer* Ahnung hat oder nicht lieber dem jeweiligen Individuum.
Von Christoph Hellwig am Mi, 25. Oktober 2000 um 13:06 #
@Anonymous > Du Quatscher,
Schauen wir mal, wer der quatscher ist ...
> probiers aus, gcc 2.96 ist ueberhaupt kein > Problem, weder mit Kernel 2.4
Würdest du bitte wenigstens ausprobieren, was du da redest? Compiliert einfach mal nen aktuellen 2.4er Kernel mit dem rh gcc snapshot und erzaehl mir dan mal, dass du nicht die -traditional & vararg makro-probleme (Linux-Bug) oder vollkomen falschen code bei bestimmten time* structs hast (gcc-Bug).
> noch mit irgendwelchen anderen Dingen. > Ich selbst bin Debian Entwickler
Ich kennen keinen Debian-Entwickler namens 'Anonymous'.
> und mich kotzt dieses Rumgehake auf Red Hat > von Leuten an die nicht wissen worum > es geht sondern nur das von anderen die > genausowenig Ahnung haben nachplappern.
Es geht nicht um Red Hat bashen. Sie können tun und lassen was sie wollen bzw für ihrem Gewinn zuträglich halten. Wenn ein Buggy gcc-Snapshot und eine Alpha-libc dazugehört: mir doch egal.
Allerdings ist einerseits ein solches, sachlich falsches Marketing-Geschwafel wie dies PR-Meldung vollkommen fehl am Platze, andereseits gehen einem diese Uninformierten 'Meine Distribution ist besser' Laberer auf den Sack.
Also, wenn ich mir durchlese, was hier so abgeht, könnte die gestern heiß diskutierte Microsoft Annonce *doch* berechtigt sein. Versteht mich nicht falsch - SuSE (YaST, glibc2) und jetzt auch RedHat (gcc 2.96) haben eben eine recht ungewöhnliche Art und Weise, wie sie ihre Distris aufbauen. Aber - und da gebe ich Bob Young recht: gleich den Vergleich mit M$ zu ziehen, halte ich für eine cholerische Reaktion. Denn immer- hin sind die Quellcodes nach wie vor GPL basiert und wem die (Un-) Version gcc-2.96 nicht passt, der kann ja auch auf "ältere" Versionen des gcc zurückgreifen. Siehe dazu auch die oben gepostete Meldung von ixsoft.
Fazit: RedHat haben sich dumm verhalten, als sie eigenmächtig eine Versionsnummer 2.96 eingeführt haben. Okay, das sollte nicht passieren. Andererseits hat sich niemand übermäßig aufgeregt, als Linus Torvalds plötzlich für einen Entwicklerkernel (2.4-testxx) eine *gerade* Versionsnummer benutzt hat.
Letzlich hat RedHat IMHO aber recht:
Spätestens *wenn* gcc 3.0 kommt (laut gcc-Team frühestens gegen Ende des Jahres) werden viele Distributoren auf diese Version umschwenken. Dann ist aber auch eine SuSE 7.1 oder Mandrake 8.x nicht mehr zu ihren Vorgängern binärkomatibel.
Aber statt uns weiter über in endlos langen Flamewars gegenseitig zu schaden, sollten wir nun endlich wieder eine Community bilden. Zwietracht kommt letzlich nur "dem Feind" also M$ zugute. Und das will doch keiner von uns, oder?!
Ich habe keine Feinde auch nicht Microsoft. Würden die ein Betriebssystem machen das mir besser gefällt und preislich akzeptabel wäre, würde ich es benutzen. Machen sie aber halt nicht. Würde auch ein MS Office für Linux benutzen wenn es mir gefällt und auch preislich konkurrieren kann.
Spätestens *wenn* gcc 3.0 kommt (laut gcc-Team frühestens gegen Ende des Jahres) werden viele Distributoren auf diese Version umschwenken. Dann ist aber auch eine SuSE 7.1 oder Mandrake 8.x nicht mehr zu ihren Vorgängern binärkomatibel.
da hast du etwas falsch verstanden. der gcc 3.0 _wird_ abwaertskompatibel zum aktuellen 2.95.2 und folgeversionen sein. die pseudoversion 2.96 von redhat ist es eben nicht. gecheckt, was die typen da abziehen?
Von Thoralf Will am Di, 24. Oktober 2000 um 13:07 #
>da hast du etwas falsch verstanden. der gcc >3.0 _wird_ abwaertskompatibel zum aktuellen >2.95.2 und folgeversionen sein. die >pseudoversion 2.96 von redhat ist es eben >nicht. gecheckt, was die typen da abziehen?
wenn der gcc abwärtskompatible zum 2.95.2. sein wird, kannst du mir dann bitte erklären, wieso der gcc 2.96-rh es nicht sein sollte? "die typen" ziehen überhaupt nichts ab. irgendwie habe ich den eindruck, als wenn es immer ein paar leute gibt, die vor lauter paranoidität nicht wissen, wovor sie noch angst haben sollen. setzt euch mal alle hin, esst nen keks und freut euch über die innovationen im linux-markt. wahrscheinlich haben die meisten den ixsoft-artikel nicht bis zu dem punkt gelesen, an dem erwähnt wurde, dass nach wie vor auch der alte gcc2.7 und 2.95 mit den alte libs als kompat-paket mitgeliefert wird. wer also unbedingt mit einen "stable"-gcc komilieren will, der kann das auch tun. ich weiss überhaupt nicht, wo es da noch probleme geben soll...
der gcc 2.96-rh ist inkompatibel, weil es die gcc-entwickler gesagt haben.
ja, ich werde paranoid und es laeuten alle alarmglocken, wenn eine software-firma durch unlautere methoden die user noetigt, die eigene software zu benutzen. das ist es, was sie abziehen.
Von Thoralf Will am Di, 24. Oktober 2000 um 15:08 #
klar doch, der gcc2.96-rh ist inkompatibel weil "die" entwickler es gesagt haben. komischerweise war nirgends in der seriösen presse davon zu lesen.
was an dem verhalten unlauter sein soll, kann ich nach wie vor nicht erkennen. wenn ein distributer den gcc 2.0 verwenden will, kann er das genauso tun wie ein ditributer der ein cvs-snapshot nimmt. daran ist absolut NICHTS unlauter.
bitte poste in zukunft mit deinem namen, damit ich deine postings ignorieren kann. es hat wenig sinn mit paranoiden menschen zu diskutieren.
nein, ich bin nicht Anonymous, aber ich wollte ein paar Sätze zu Deiner Aussage hinzufügen.
Wie bereits Anon bemerkt hat, wird die Version 3.0 mit der Version 2.95.2 vollständig kompatibel sein. Die Kompatibilität zu der von RedHat benutzten Version 2.96 wird dagegen nicht gewährleistet sein, was das gcc-Team bereits angekündigt hat. Diese Ankündigung findest Du unter: http://gcc.gnu.org/ml/gcc-announce/2000/msg00003.html Grund für diese Inkompatibilität wird das geänderte Binäre-Format sein. Es ist nur verständlich, dass das gcc-Team das Format während einer Entwicklung mehrmals ändern wird, was auch Gerald Pfeifer angekündigt hat: "2.96 is not a formal GCC release nor will there ever be such a release. Rather, GCC 2.96 has been the code-name for our development branch that will eventually become GCC 3.0". Man beachte bitte den kleinen Unterschied, der in diesem Fall "eventuell" heißt.
Aus diesem Grund ist die von RH veröffentlichte Stellungnahme ein Witz in meinen Augen. Es kann nicht sein, dass unter dem Deckmantel des "Fortschritts" oder gar "Innovation" (egal, wie lächerlich es klingt) eine zu anderen Distributionen inkompatible Version erstellt wird.
>> "2.96 is not a formal GCC release nor will there ever be such a release. Rather, GCC 2.96 has been the code-name for our development branch that will eventually become GCC 3.0". Man beachte bitte den kleinen Unterschied, der in diesem Fall "eventuell" heißt. <<
eventually heißt nicht "eventuell" sondern "schließlich" oder auch "endlich" - das ist doch ein bischen was anderes !
[zitat] eventually heißt nicht "eventuell" sondern "schließlich" oder auch "endlich" - das ist doch ein bischen was anderes ! [/zitat]
das ist in diesem kontext egal. 3.0 wird kompatibel zu 2.95.2 sein und zu 2.96-rh nicht.
was bedeutet das fuer mich? ein beispiel: ich stolpere bei rpmfind.net ueber ein rpm, das ich installieren moechte. doch ach, die binaries sind mit dem gcc 2.96-rh kompiliert. also muss ich mir die sourcen besorgen und sie selber kompilieren. aber vielleicht bin ich dazu nicht in der lage oder habe einfach keine lust. tja, da werde ich wohl redhat 7.0 installieren muessen. und das ist nur eines der vielen probleme, die bei redhat 7.0 auftreten werden.
der vorwurf der gezielten inkompatiblitaet steht nach wie vor im raum. unlauter ist es auf jeden fall, sich einen cvs-snapshot zu ziehen von dem man weiss, dass er inkompatibel ist und ihn dann ohne sich mit den entwicklern abzusprechen "2.96" zu nennen .
Von Christoph Hellwig am Mi, 25. Oktober 2000 um 13:49 #
@Anonymous > da hast du etwas falsch verstanden. der gc > 3.0 _wird_ abwaertskompatibel zum > aktuellen 2.95.2 und folgeversionen sein.
Nein. Gcc 3.0 wird nicht zum gcc 2.95.x (C++-Binär) abwärtskompatibel sein. Allerdings wird er warscheinlich auch nicht zum RedHat pseudo-gcc-2.96 kompatibel sein und das ist der Punkt.
Fazit: RH würde es nicht schaden, wenn sie eine Version einsetzen die allgemein als stable gilt. Wer will, kann dann ja zusätzlich eine andere Version unterstützen. Also RH, haltet euch dran!
Von Thoralf Will am Di, 24. Oktober 2000 um 15:40 #
das ding ist keine OFFIZIELLER 2.96. aber rh hat das teil einfach so genannt, wobei deren pakete im allgemeinen sowieso die endung "-rh" tragen und daher als redhat-pakete zu erkennen sind.
Kann mir jemand erklaeren warum die mit gcc2.96 compilierten Pakete nicht mit den alten kompatibel sind? Haben die neuen irgendwelche Probleme mit Libraries oder so? Und wieso nur bei C++-Programmen?
Ich verstehe aber ehrlich gesagt viele hier nicht. Die meisten schreien nach schnellen Veröffentlichungen (zB KDE2 und Kernel 2.4) und probieren jede auch noch so unstabiele Alpha oder Beta aus, weil sie angeblich die innovativen Experten sind, sind aber zu konservativ sich auf einige Neuheiten einzustellen. Wenn der 2.4er Kernel heute veröffentlicht würde, würden diese User ihn ohne weiteres installieren, ohne das für sie eine Notwendigkeit besteht oder ob sich noch Bugs in ihm befinden - aber Hauptsache neu....
Die meisten, die sich hier als Experten darstellen geiern in Wirklichkeit nur nach neuen Releases (die es in der Windows-Welt nicht so häufig gibt). Wenn Ihr so tolle Experten seit, dann entscheidet für Euch, ob Ihr den gcc 2.96 braucht oder nicht und sucht Euch danach die Distribution aus. Oder, da Ihr Experten seit: Es wird alles mitgeliefert damit Ihr Euch Eure eigenen RPM's im "alten" Format bauen könnt.
...und vergesst nicht: Linux ist nur der Kernel. Der Rest, den Ihr auf der Festplatte habt ist die Distribution und das schöne ist doch, das es für jeden etwas gibt womit er zurecht kommt.
Hier ist zB kein Aufschrei gekommen, als die SuSE 7.0 mit dem "2.2.17" Kernel erschienen ist. Den gab es noch nichteinmal bei Erscheinen der Distribution. Das finde ich viel unmöglicher. Nur irgendwo auf der Packung steht, daß es gepatchter 2.2.16er ist, der quasi als 2.2.17 angesehen werden kann. Das verwirrt doch mehr. Aber SuSE-User: Nicht traurig sein, läuft doch auch ganz stabil, oder!?!
Also, wem RH7 nicht passt: Distri. wechseln, selber compilieren, oder RH6.x updaten. Für ca. 90,- DM könnt Ihr selbst mit einem langsamen Modem viel neues saugen.
--------------------- [x] ja, ich habe verstanden, worum es geht ---------------------
BTW: Der gcc 3.0 wird nicht abwärtskompatibel sein, weil es ein C# Compiler ist ;-)
OH GOTT!!! Leute, echt, ich könnt immer öfter heulen, wie sehr sich mittlerweile alle hier zerstreiten. Seid friedlich und haltet mehr zusammen, sonst werden wir immer öfter Spott von Micro$oft ernten. Aalso, ich denke mal, Red Hat stellt seit Jahren ne Distribution zusammen und somit werden die schon wissen was die tun. Diejenigen, die wirklich wissen, was nun genau hinter der Thematik steckt, werden sich eh ne Debian zusammenbasteln (oder Linux-From-Scratch) oder was auch immer... und diejenigen die es nicht wissen, sollten auch nicht auf Red Hat schimpfen. Und ich denke mal, die meisten User, die sich ihr Linux selbst zusammenschustern können, werden es auch tun und somit nicht grossartig drüber nachdenken.
Red Hat, SuSE, Mandrake, was-weiss-ich-linux: alle haben sie ihre Stärken und Schwächen, aber denkt doch mal an den Hauptvorteil von Linux: es gibt nichts, was man nicht selbst wieder "geradebiegen" kann.
Wiso reden hier so viele über "Inkompatibilität zu anderen Distributionen"? Warum schimpft keiner auf Debian oder auf den Rest? Schließlich verwendet Debian auch nicht das RPM-Format. Wieso schimpft keiner auf SuSE? Den CodeWarrior gibt es auch in einer SuSE und einer RH Variante. Es sind aber mehr Distris RH kompatibel!!! Für die, die sich am meisten über die Version 2.96 aufregen, weil sie das Programm vielleicht nicht kennen: Das ist eine IDE um Programme zu entwickeln.
Wieso gibt es GTK? Ich kann mein neues KDE2 nicht dagegen linken. Fragen über Fragen... Wieso hat vi andere Tastaturbefehle als emacs?
Schimpft schon mal auf Borland!!!! Wenn Kylx für C++ kommt, wird man die Sourcen von dieser IDE auch nicht mit gcc compilieren können! Ups,.... und jetzt?
Von Frank Arnold am Di, 24. Oktober 2000 um 21:08 #
...eine art Tabelle in eine Programmdatei vom Linker einbauen lassen, in welchem steht: wo sich die Funktionen einer externen Bibliothek befinden(name der Bibliothek) und wie sie heissen (funktions-,variablenname). Diese externe Bibliothek ist damit Quasi mit dem Programmodul "verlinkt". Während der Laufzeit ("Runtime Linking"), werden alle Bibliotheken die "verlinkt" worden sind automatisch in den Adressbereich der Anwendung geladen. Damit hat man jetzt innerhalb des Programms Zugriff auf die externen Funktionen (und Variablen) (sie befinden sich ja jetzt im Speicherbereich auf den das Programm zugriff hat -Proteced Mode
Meiner Meinung sind es solche Aktionen von Redhat, die den Anwendern Linux verleiden. Wie oft hatte ich schon den Fall: Programm laeuft nicht, weil es glibc2.1.2 benotigt es ist aber nur glibc 2.0 auf dem System, oder Programm laeuft nicht, weil es mit egcs kompiliert wurde auf dem System ist aber nur gcc. Ich moechte es wirklich stark bezweifeln, dass ein Anwender wirklich Vorteile hat, dass er die allerneuste Version irgendeiner Library oder eines Compilers auf dem System hat. Von weit fortgeschrittenen Programmen wie glibc oder gcc werden die neusten Features von den meisten wahrscheinlich nie bemerkt.
also weder etwas gegen IXsoft noch gegen RedHat. Zumindest nicht per se.
Aber was auf der ixsoft Seite steht ist schlicht die Unwarheit.
Zum einen ist dieser Compiler ein compiler der von RedHat verändert wurde, ein cvs mit patches. Demnach ist er ein proprietärer d.h. von RedHat gemachter compiler. GCC leistet keinerlei support zu diesem Compiler (nachzulesen auf der GCC liste unter gcc.gnu.org).
Zum anderen ist der compiler nicht binärkompatibel und fertig. Er wird auch nicht wie behauptet mit 3.0 kompatibel sein (libstdc-v3?). Zumindest dann nicht wenn die GCC Entwickler unabhängig von RedHat agieren dürfen. Davon ist erstmal auszugehen.
Die GLIBC ist eine alpha Version die so auch noch nicht existiert. Auf der Verpackung von RedHat steht glibc 2.2 und gcc 2.96. Beides existiert in dieser Form nicht und ist demnach schlicht gelogen.
Ob nun RedHat versucht mit hilfe ihrer momentanen Stellung mehr MArktmacht durch die "inkompatibiliesierung" ihrer Distri durchzusetzen oder ob es nur der Versuch ist einen Schritt nach vorne zu machen, sei dahingestellt.
Auch der offene Brief von Bob Young ist ein Scherz. Wagter der doch zu behaupten "Wer gegen RedHat ist is nur für Microsoft". Das passt ganz gut zu der Vorstellung das RedHat der Erschaffer von FreeSoftware ist.
Steigt da jemandem sein Erfolg zu Kopf ?
Richtig ist:
Es existiert kein gcc-2.96. Das ist lediglich eine RedHat version (vgl. Diskussion LKML sowie GCCML).
Es existiert bisher keine Glibc2.2 wie auf der Verpackung angegeben.
Falsch ist der Vergleich mit dem Kernel oder KDE.
Allerdings liefert auch glaube ich keine Distri einen ungepatchten Standardkernel mit. Aber nun gut.
Aber RailroadT.2. ist gut, und läuft auch unter Debian. Demnach ist die BOX nicht total rausgeschmissenes Geld.
Von Bernd Hentig am Mi, 25. Oktober 2000 um 10:03 #
Also, das kann ich jetzt so nicht stehen lassen.
Nach Aussagen der Entwickler sind alle Patches "Frei" und waren im CVS. Von "proprietär" kann keine Rede sein, also das ist schlicht unwahr. Wenn ich eine Erweiterung für ein beliebiges GPL-Programm machen, meine Änderungen ins CVS stecke und die auch nicht gelöscht werden, dann ist das eine freie Software und keine proprietäre. Punkt.
Der Vergleich zwischen Red Hat und M$ wurde aufgrund verschiedener Artikel in slashdot usw. gezogen, wo genau das Thema diskutiert wurde, daher vermutlich die Stellungnahme von Bob Young ?
Die Kompatiblität betreffend habe ich die Aussage bekommen (die ich mal einfach ungeprüft geglaubt habe), dass gcc3.0 mit gcc 2.95.2 nicht kompatibel sein kann, weil Symbol Mangling (einem C++-Entwickler wird das jetzt was sagen) und die Art und Weise der Benutzung der ELF-sections für exception handling usw. von gcc 2.95.2 einfach es nicht mehr hergaben, die Ansprüche von ANSI C++ zu erfüllen. Vielleicht kann man mit viel Mühe und Verrenkungen einen compat-gcc (ähnlich wie die ganzen compat-glibc und compat-stdc++, wo jetzt langsam keiner mehr durchsteigt) schaffen, aber wozu denn nur ? Das Problem betrifft ausschließlich C++ und dort wohl vor allem mal wieder libstdc++. Warum muss ich denn mit Compilern von vor x Jahren unbedingt C++kompatibel sein ? Es wird doch alleine schon aufgrund der library-Abhängigkeiten eh keiner ein Binary von Red Hat 7.0 unter Suse 7.0 zum Laufen bewegen, also muss man sowieso neu compilieren. Wozu die ganze Aufregung dann ?
Meine persönliche Meinung ist die, dass die Erweiterungen von Red Hat absolut notwendig waren, um einen ANSI C++-Compiler zu haben, der sich auch an den Standard hält; gerade bei vielen Entwicklerfirmen ist das absolut wichtig, wie ich aus Erfahrung weiß. Ob gcc 3.0 dazu dann abwärtskompatibel ist, weiß wohl in Wahrheit keiner so recht. Ich werte die Aussage "gcc 3.0 wird inkompatibel zu 2.96" eher als eine Trotzreaktion einer beleidigten (und evt. zu Unrecht übergangenen) Leberwurst anstatt eines objektiven Ansatzes, die eine technische Lösung aller Probleme bringt.
Ich denke, alle sollten sich an einen Tisch setzen (also Red Hat, die genervten gcc-Entwickler, und vielleicht ein paar andere Distributoren wie Suse und Caldera), damit wir zumindest bei so wichtigen Sachen wie gcc, glibc und libstc++ einen einheitlichen Standard haben, wo alle Distributoren drauf aufbauen können, beim Kernel geht das ja auch. Die LSB ist ja sowieso nicht durchzusetzen, aber vielleicht ein etwas kleinerer Standard, der zumindest es ermöglicht in ferner Zukunft einmal binär kompatible Programme zwischen verschiedenen Linux-Distributionen auszutauschen - das ist heute leider nur ein unwirklicher Traum.
RedHat meint, wie auf der Verpackung von RH7.0 angegeben, es handele sich um gcc-2.96 sowie glibc2.2. Diese existieren in dieser Form nicht.
Die Idee das RedHat versucht eine Inkompatible Version zu stricken um somit Marktvorteile zu erlangen ist auch von namhaften Entwicklern vorgebracht worden (bitte siehe hierzu der Thread auf der LKML sowie auf der GCC-ML).
Es geht mir hierbei nicht darum ob gcc-redhat-2.96 (der compiler meldet sich soweit ich weiss eh als redhat version) mit 2.95.2 kompatibel ist oder nicht oder ob gcc-3.0 mit gcc-2.95.2 kompatibel ist (sehr unwahrscheinlich) sondern darum das von euch gesagt wurde gcc-2.96 hat eine technologie die demnächst in andere Distris einziehen wird.
Das ist schlicht falsch.
Es ist nach derzeitigem Kenntnisstand anzunehmen das Binaries die unter gcc-redhat-2.96 gebacken wurden nicht unter einer distri mit gcc-3.0 libraries laufen werden.
Das ist nicht abzustreiten und nachlesbar auf der GCC-ML.
Die glibc existiert auch so nicth und dort wurden ähnliche Verlautbarungen diskutiert wie bei GCC.
Von Frank Arnold am Mi, 25. Oktober 2000 um 22:45 #
Tja Bernd, wie objektiv wird wohl einer reden wenn er selbst davon (finanziell)betroffen ist? Ich nehme mal nicht an das viele Poster hier an Eurer Halloween mitarbeiten...
Wenn sich irgendein Distributor einen CVS-Branch zieht, der weder als pre-release noch in andere Weise für den produktiven Einsatz gedacht(und angeraten) ist, brauch er sich nicht über "Schläge" wundern. Es geht ja hier nicht um irgendein sekundäres Tool, sondern um eines der wichtigsten Systemtools überhaupt. Da muss man sich schon Gefallen lassen, dass bei befürchteten Inkompatibilitäten einige Leute den Mund aufmachen...
Ich denke ich muß hier einmal - als Laie sozusagen - eine Stellungnahme abgeben. Ich hab mir jetzt den ganzen Thread reingezogen und bin mehr als nur erheitert.
Kurz vorweg: Ich surf hier so rum in meiner Mittaxpause, um mich ein wenig auf dem laufenden zu halten, was es so am Sektor gibt, bin aber weit weg davon ein Experte zu sein.
Es muss ja ein Schock gewesen sein, als Red Hat, das ja immer als der quasi unbefleckte "große" kommerzielle Distributor dargestellt wurde(Im Gegensatz zu Suse, das sind ja wohl die Bösen), einfach einen Compiler reinhaut, der kein offizieller Release ist. *Bumm* Da fallen dann Worte und Sätze von seitens der großen RH Verteidiger (die es offensichtlich selber noch nicht fassen können was da passiert ist), die in einer wissenschaftlichen Diskussion bei jedem Symposium zum Saalverweis führen würden (Und da kenn ich mich aus). Das Aufspielen als beleidigtes Kind, nur weil der Liebling auch Geld verdienen will ist schon ein wenig übertrieben, oder????
Falls es wer noch nicht ganz eingesehen hat. Die Distriutoren am Markt sind nicht Brüder, die sich in einer großen Idee vebunden fühlen,sondern stehen in beinharter Konkurenz zueinander. Und wenn das Geschäft nicht läuft dann gibts in zwei jahren auch RH nicht mehr. Hier gehts ganz einfach um Kohle. Und wenn RH glaubt das so tun zu müssen, dann sollen sie das doch auch. So schwer es für die Leute zu akzeptieren ist, die mit Linux seit Jahren auf du und du stehen, aber über den Erfolg von Linux am Desktop -und damit der Distributoren-, entscheiden nicht die wirklich fähigen User, sondern Leute wie ich, die nach 60 Stunden Wochenarbeitszeit ein einfaches System zu Hause wollen, und einfach keine Zeit haben, sich die WEs mit Systemadministration für den Heim-PC zu verbraten. Und diesen Usern, also DAUs wie mir, ist es grundsätzlich absolut egal welche Nummer der Compiler hat und was der so alles kann , Hauptsache ist, ich kann in kurzer Zeit, mit wenig Geld ein System am PC aufsetzen, das funktioniert. Klarerweise: Für Anwender wie mich, also für die die Distris dann auch zahlen, sind Punkte wie z.B. Kompatibilität verschiedener Distributionsversionen eines Herstellers Kaufentscheidungspunkte. Aber: Wenn die entscheidenden Punkte nicht da sind wird's der Markt bereinigen.
DAS ist ja der Vorteil von Linux. Das nicht nur einer das ist, der uns sagt was Sache ist. Ich brauch keine Office Version Nummer 225, wo die Büroklammern singen können. In hab bei Linux einfach eine Wahl. Wir alle haben die Auswahl, und keiner von uns muss. Nicht RH nicht SUSE nicht Madrake.
Und noch eins: vielleicht wär es für einige erst mal gut so im Stillen bis zehn zu zählen und ein bisserl nachzudenken bevor sie ihr infantiles Gewäsch in ein Forum schmieren. Obwohl, dann hätt ich vielleicht nicht so viel Spass in meiner Mittaxpause....
Du sprichst mir aus der Seele. Alle träumen selig von fröhlicher Einigkeit der Linux-Distributoren, weil, es ist ja im Sinne des Open-Source, gell? Aber da draussen am freien Markt gehts halt härter zu...
Dass mit gcc 2.95.2 keine stabilen Distris zu bauen sind, ist eine Frechheit gegenueber anderen Distributoren. Ob andere Distributoren demnaechst ebenfalls mit CVS-Snapshot-Compilern Distris bauen, wage ich zu bezweifeln.
Schmiert Euch Eure Redhat 7.0 in die Haare!
ich habe bereits die beta von rh7 vor einigen wochen getestet und keine wirklich groben fehler entdecken können. wenn die rothüte bei der final nicht alles über den haufen geworfen haben, dürfte die distri durchaus nicht so schlecht sein.
btw: bei uns in der firma vergeht kaum ein tag, an dem ich nicht das gleiche ("...in die haare schmieren...") über die verschiedenen suse-versionen denke die hier auf diversen servern werkeln.
grus,
thoralf
BTW: sicher hab ich schon RH installiert, bin also nicht minder genial ...
und für eine distribution ist es enorm wichtig ob sie mir gefällt oder nicht. was hilft mir der schönste compiler und die tollsten bibliotheken, wenn ich mir den kram doch wieder komplett neu bauen muss, weil der aufbau derart verbockt ist, dass ich selbst mit einem dutzend symbolischer links keine vernünftige struktur in das system bekomme.
ich hatte mit keinen komatibilitätsproblemen bei der rh7beta zu kämpfen, die struktur passt und funktioniert. als vergleich habe ich suse herangezogen, weil die ihre configfiles an den unmöglichsten stellen ablegen und die rc.config in meinen augen die unelegateste lösung ist, die man nur finden kann.
nebenbei habe ich noch eine mail von Patrick Spingys mit dem hinweis auf eine seite zur kompatibilität von gcc bekommen. hab sie selbst noch nicht komplett gelesen:
http://www.ixsoft.de/gcc296-de.html
gruss,
thoralf
http://www.ixsoft.de/gcc296-de.html
gruss,
thoralf
Anstatt das ixsoft/RedHat Marketing zu zitieren Frag mal lieber die Entwickler des gcc.
Wir können ja eine Wette abschliessen ob der Redhat gcc snapshot und gcc 3.0 C++-Binär-Kompatibel sind ...
Eigentlich ist es sowieso egal, das bisher kaum ein gcc zum vorigen C++-Binär-Kompatibel war und ein großteil der in C++ geschriebenen kommerziellen Software sowieso mit einer eigenen gebundelten libstdc++ kommen.
(libstdc++ ist das eigentliche kompatblitaetsproblem, warum die immernoch mit dem gcc gebundelt wird anstatt ein separates packet zu sein ist eine ganz andere Frage ...)
Christoph
es würde mich wundern, wenn der gcc2.96-rh inkompatibler zum gcc3.0 als der aktuelle 2.95.x wäre.
aber ich lasse mich gern eines besseren belehren.
gruss,
thoralf
> es würde mich wundern, wenn der gcc2.96-rh
inkompatibler zum gcc3.0 als der aktuelle 2.95.x wäre.
"Inkompatibler" finde ich einen komischen ausdruck: Entweder etwas ist kompatibel, oder es ist nicht. Und der rh Gcc-Snapshot ist zu gcc 2.95.x nicht kompatibel und wird mit grosser Warscheinlichkeit zu gcc 3.0 nicht kompatibel sein.
Das ehr archtiekturell mehr vom gcc 3.0 hat bezweifle ich garnicht.
Christoph
gcc 296-rh ist weder nach vorn, noch zurück kompatibel, während der 2.95.x doch immerhin zurück kompatibel ist
Das, was mir ein wenig Gedanken macht, ist die Kompatibilitaet der RH RPMs zu anderen Distris. Immerhin ist nicht gerade ein unwesentlicher Teil der RPMs, die man so im iNet findet, fuer RH. So far macht meine Mandrake damit keine Probleme (ist ja nen RH Klon), aber wenn die Teile wirklich nicht mehr binaerkompatibel sind?!?
Naja, mal auf den Ideenreichtum der Franzosen hoffen :)
Gruss
Sven
Sogut wie der aktuelle CVS-Snapshot vom gcc auch sein mag, es ist eben noch kein offizielles stable-release und damit für den Produktionseinsatz nicht zu empfehlen. Diese einfache Logik hat uns bisjetzt davor geschützt ein instabiles und damit kaum benutzbares Linux zu erhalten.
Also Leute, lasst die Finger von dem neuen RedHat! Da die meisten eh nur das update auf XFree4 bzw. KDE2 interessiert, reicht auch der Kauf einer Linux-Zeitungs-CD bzw. der eigene download. Stabilität und Kompatibiliät sollten wichtiger sein, als der "run" auf irgendeine neue Version einer Distribution.
Save your money!
im Prinzip ihre RedHat 5.1 oder
SuSE 6.0 nach und nach updated
haben. Ich finde dieses "oh, neue
Version meiner Lieblingsdistri?!
Sofort kaufen!" Getue ohnehin
nervig. Dann hätten die Leute
auch weiterhin Windoze benutzen
können. Es geht bei Linux eben
*nicht* darum, immer "das
neueste" zu haben, sondern
darum, ein bestehendes System
nach und nach zu erweitern.
Trotzdem ist RedHat nach wie vor
eine gute Distri. Und Fehler
hat auch SuSE oder ixSoft schon
gemacht. Hat beiden nicht
geschadet.
Und wer lange genug mit Linux
arbeitet, der wird sicherlich
in der Lage sein, einen KDE-2.0
tarball oder SRPMS zu
kompilieren. Dank RPM oder auto-
config ist das ja mittlerweile
recht einfach und kommt auch
vielgeplagten Admins entgegen.
Wer dennoch ob der vielen Wieder-
sprüche in der Linuxwelt "kalte
Füße" bekommt, dem sei (wie so
oft!) FreeBSD nahegelegt. Dort
nimmt man es sogar mit den
Sicherheitslücken bestimmter
Programme dermaßen ernst, daß
z.B. Lynx eine gewisse Zeit nicht
als Port verfügbar war, da es
den Sicherheitsanforderungen des
FreeBSD Teams nicht gerecht
wurde. RedHat, SuSE und Co. haben
das Paket trotzdem beigefügt und
darauf vertraut, daß sich die
Anwender die entsprechenden
Updates schon von selbst
einspielen werden.
Nicht, daß ich jetzt hier einen
Flamewar beschwören möchte. Ich
bin lediglich der Ansicht, daß es
überall etwas zu kritisieren
gibt.
lodger
gruss,
thoralf
Erstens: falls Du mich als
"Quatscher" bezeichnet hast:
mäßige Deinen Ton. Wenn Du mein
Posting gelesen hättest, statt es
zu überfliegen, hättest Du
gelesen, daß ich RH nach wie vor
für eine tolle Distri halte.
Und stell' Dir vor, ich setzte
sie sogar ein. Was man von Dir
als "Debian Entwickler" ja wohl
kaum erwarten dürfte...
Und außerdem habe ich weiter
unten im Forum ja bereits die
Entscheidung von RH für den
gcc 2.96 befürwortet.
Also, lieber Anonymous: kein
Grund zur Panik...
Und überlasse die Entscheidung,
*wer* Ahnung hat oder nicht
lieber dem jeweiligen Individuum.
lodger
> Du Quatscher,
Schauen wir mal, wer der quatscher ist ...
> probiers aus, gcc 2.96 ist ueberhaupt kein
> Problem, weder mit Kernel 2.4
Würdest du bitte wenigstens ausprobieren,
was du da redest?
Compiliert einfach mal nen aktuellen 2.4er Kernel mit dem rh gcc snapshot und erzaehl mir dan mal, dass du nicht die -traditional
& vararg makro-probleme (Linux-Bug) oder vollkomen falschen code bei bestimmten time* structs hast (gcc-Bug).
> noch mit irgendwelchen anderen Dingen.
> Ich selbst bin Debian Entwickler
Ich kennen keinen Debian-Entwickler namens 'Anonymous'.
> und mich kotzt dieses Rumgehake auf Red Hat
> von Leuten an die nicht wissen worum
> es geht sondern nur das von anderen die
> genausowenig Ahnung haben nachplappern.
Es geht nicht um Red Hat bashen. Sie können tun und lassen was sie wollen bzw für ihrem Gewinn zuträglich halten. Wenn ein Buggy gcc-Snapshot und eine Alpha-libc dazugehört: mir doch egal.
Allerdings ist einerseits ein solches, sachlich falsches Marketing-Geschwafel wie dies PR-Meldung vollkommen fehl am Platze, andereseits gehen einem diese Uninformierten 'Meine Distribution ist besser' Laberer auf den Sack.
Christoph
hier so abgeht, könnte die
gestern heiß diskutierte
Microsoft Annonce *doch*
berechtigt sein. Versteht mich
nicht falsch - SuSE (YaST,
glibc2) und jetzt auch RedHat (gcc 2.96) haben eben eine recht
ungewöhnliche Art und Weise, wie
sie ihre Distris aufbauen. Aber -
und da gebe ich Bob Young recht:
gleich den Vergleich mit M$ zu
ziehen, halte ich für eine
cholerische Reaktion. Denn immer-
hin sind die Quellcodes nach wie
vor GPL basiert und wem die (Un-)
Version gcc-2.96 nicht passt,
der kann ja auch auf "ältere"
Versionen des gcc zurückgreifen.
Siehe dazu auch die oben
gepostete Meldung von ixsoft.
Fazit: RedHat haben sich dumm verhalten, als sie eigenmächtig eine Versionsnummer 2.96
eingeführt haben. Okay, das sollte nicht passieren.
Andererseits hat sich niemand
übermäßig aufgeregt, als
Linus Torvalds plötzlich für
einen Entwicklerkernel (2.4-testxx) eine *gerade*
Versionsnummer benutzt hat.
Letzlich hat RedHat IMHO aber
recht:
Spätestens *wenn* gcc 3.0 kommt
(laut gcc-Team frühestens gegen
Ende des Jahres) werden viele
Distributoren auf diese Version
umschwenken. Dann ist aber auch
eine SuSE 7.1 oder Mandrake 8.x
nicht mehr zu ihren Vorgängern
binärkomatibel.
Aber statt uns weiter über in
endlos langen Flamewars
gegenseitig zu schaden, sollten
wir nun endlich wieder eine
Community bilden. Zwietracht
kommt letzlich nur "dem Feind"
also M$ zugute. Und das will doch
keiner von uns, oder?!
lodger
Spätestens *wenn* gcc 3.0 kommt
(laut gcc-Team frühestens gegen
Ende des Jahres) werden viele
Distributoren auf diese Version
umschwenken. Dann ist aber auch
eine SuSE 7.1 oder Mandrake 8.x
nicht mehr zu ihren Vorgängern
binärkomatibel.
da hast du etwas falsch verstanden. der gcc 3.0 _wird_ abwaertskompatibel zum aktuellen 2.95.2 und folgeversionen sein. die pseudoversion 2.96 von redhat ist es eben nicht. gecheckt, was die typen da abziehen?
wenn der gcc abwärtskompatible zum 2.95.2. sein wird, kannst du mir dann bitte erklären, wieso der gcc 2.96-rh es nicht sein sollte?
"die typen" ziehen überhaupt nichts ab. irgendwie habe ich den eindruck, als wenn es immer ein paar leute gibt, die vor lauter paranoidität nicht wissen, wovor sie noch angst haben sollen.
setzt euch mal alle hin, esst nen keks und freut euch über die innovationen im linux-markt. wahrscheinlich haben die meisten den ixsoft-artikel nicht bis zu dem punkt gelesen, an dem erwähnt wurde, dass nach wie vor auch der alte gcc2.7 und 2.95 mit den alte libs als kompat-paket mitgeliefert wird. wer also unbedingt mit einen "stable"-gcc komilieren will, der kann das auch tun. ich weiss überhaupt nicht, wo es da noch probleme geben soll...
gruss,
thoralf
ja, ich werde paranoid und es laeuten alle alarmglocken, wenn eine software-firma durch unlautere methoden die user noetigt, die eigene software zu benutzen. das ist es, was sie abziehen.
komischerweise war nirgends in der seriösen presse davon zu lesen.
was an dem verhalten unlauter sein soll, kann ich nach wie vor nicht erkennen. wenn ein distributer den gcc 2.0 verwenden will, kann er das genauso tun wie ein ditributer der ein cvs-snapshot nimmt. daran ist absolut NICHTS unlauter.
bitte poste in zukunft mit deinem namen, damit ich deine postings ignorieren kann. es hat wenig sinn mit paranoiden menschen zu diskutieren.
gruss,
thoralf
nein, ich bin nicht Anonymous, aber ich wollte ein paar Sätze zu Deiner Aussage hinzufügen.
Wie bereits Anon bemerkt hat, wird die Version 3.0 mit der Version 2.95.2 vollständig kompatibel sein. Die Kompatibilität zu der von RedHat benutzten Version 2.96 wird dagegen nicht gewährleistet sein, was das gcc-Team bereits angekündigt hat. Diese Ankündigung findest Du unter: http://gcc.gnu.org/ml/gcc-announce/2000/msg00003.html
Grund für diese Inkompatibilität wird das geänderte Binäre-Format sein. Es ist nur verständlich, dass das gcc-Team das Format während einer Entwicklung mehrmals ändern wird, was auch Gerald Pfeifer angekündigt hat:
"2.96 is not a formal GCC release nor will there ever be such a release. Rather, GCC 2.96 has been the code-name for our development branch that will eventually become GCC 3.0". Man beachte bitte den kleinen Unterschied, der in diesem Fall "eventuell" heißt.
Aus diesem Grund ist die von RH veröffentlichte Stellungnahme ein Witz in meinen Augen. Es kann nicht sein, dass unter dem Deckmantel des "Fortschritts" oder gar "Innovation" (egal, wie lächerlich es klingt) eine zu anderen Distributionen inkompatible Version erstellt wird.
<<
eventually heißt nicht "eventuell" sondern "schließlich" oder auch "endlich" - das ist doch ein bischen was anderes !
eventually heißt nicht "eventuell" sondern "schließlich" oder auch "endlich" - das ist doch ein bischen was anderes !
[/zitat]
das ist in diesem kontext egal. 3.0 wird kompatibel zu 2.95.2 sein und zu 2.96-rh nicht.
was bedeutet das fuer mich? ein beispiel: ich stolpere bei rpmfind.net ueber ein rpm, das ich installieren moechte. doch ach, die binaries sind mit dem gcc 2.96-rh kompiliert. also muss ich mir die sourcen besorgen und sie selber kompilieren. aber vielleicht bin ich dazu nicht in der lage oder habe einfach keine lust. tja, da werde ich wohl redhat 7.0 installieren muessen. und das ist nur eines der vielen probleme, die bei redhat 7.0 auftreten werden.
der vorwurf der gezielten inkompatiblitaet steht nach wie vor im raum. unlauter ist es auf jeden fall, sich einen cvs-snapshot zu ziehen von dem man weiss, dass er inkompatibel ist und ihn dann ohne sich mit den entwicklern abzusprechen "2.96" zu nennen
.
> da hast du etwas falsch verstanden. der gc
> 3.0 _wird_ abwaertskompatibel zum
> aktuellen 2.95.2 und folgeversionen sein.
Nein. Gcc 3.0 wird nicht zum gcc 2.95.x (C++-Binär) abwärtskompatibel sein. Allerdings wird er warscheinlich auch nicht zum RedHat pseudo-gcc-2.96 kompatibel sein und das ist der Punkt.
Christoph
gruss,
thoralf
Siehe die offizielle Bekanntgabe des gcc steering commitee: http://gcc.gnu.org/gcc-2.96.html
Christoph
gruss,
thoralf
Und wieso nur bei C++-Programmen?
ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/mandrake-devel/contrib/i586/
Ich verstehe aber ehrlich gesagt viele hier nicht. Die meisten schreien nach schnellen Veröffentlichungen (zB KDE2 und Kernel 2.4) und probieren jede auch noch so unstabiele Alpha oder Beta aus, weil sie angeblich die innovativen Experten sind, sind aber zu konservativ sich auf einige Neuheiten einzustellen. Wenn der 2.4er Kernel heute veröffentlicht würde, würden diese User ihn ohne weiteres installieren, ohne das für sie eine Notwendigkeit besteht oder ob sich noch Bugs in ihm befinden - aber Hauptsache neu....
Die meisten, die sich hier als Experten darstellen geiern in Wirklichkeit nur nach neuen Releases (die es in der Windows-Welt nicht so häufig gibt). Wenn Ihr so tolle Experten seit, dann entscheidet für Euch, ob Ihr den gcc 2.96 braucht oder nicht und sucht Euch danach die Distribution aus. Oder, da Ihr Experten seit: Es wird alles mitgeliefert damit Ihr Euch Eure eigenen RPM's im "alten" Format bauen könnt.
...und vergesst nicht: Linux ist nur der Kernel. Der Rest, den Ihr auf der Festplatte habt ist die Distribution und das schöne ist doch, das es für jeden etwas gibt womit er zurecht kommt.
Hier ist zB kein Aufschrei gekommen, als die SuSE 7.0 mit dem "2.2.17" Kernel erschienen ist. Den gab es noch nichteinmal bei Erscheinen der Distribution. Das finde ich viel unmöglicher. Nur irgendwo auf der Packung steht, daß es gepatchter 2.2.16er ist, der quasi als 2.2.17 angesehen werden kann. Das verwirrt doch mehr.
Aber SuSE-User: Nicht traurig sein, läuft doch auch ganz stabil, oder!?!
Also, wem RH7 nicht passt: Distri. wechseln, selber compilieren, oder RH6.x updaten. Für ca. 90,- DM könnt Ihr selbst mit einem langsamen Modem viel neues saugen.
---------------------
[x] ja, ich habe verstanden, worum es geht
---------------------
BTW: Der gcc 3.0 wird nicht abwärtskompatibel sein, weil es ein C# Compiler ist ;-)
PS: ...mal schauen ob's alle "Experten" merken
Red Hat, SuSE, Mandrake, was-weiss-ich-linux: alle haben sie ihre Stärken und Schwächen, aber denkt doch mal an den Hauptvorteil von Linux: es gibt nichts, was man nicht selbst wieder "geradebiegen" kann.
My 2 Cents...
Warum schimpft keiner auf Debian oder auf den Rest? Schließlich verwendet Debian auch nicht das RPM-Format.
Wieso schimpft keiner auf SuSE? Den CodeWarrior gibt es auch in einer SuSE und einer RH Variante. Es sind aber mehr Distris RH kompatibel!!! Für die, die sich am meisten über die Version 2.96 aufregen, weil sie das Programm vielleicht nicht kennen: Das ist eine IDE um Programme zu entwickeln.
Wieso gibt es GTK? Ich kann mein neues KDE2 nicht dagegen linken.
Fragen über Fragen...
Wieso hat vi andere Tastaturbefehle als emacs?
Schimpft schon mal auf Borland!!!! Wenn Kylx für C++ kommt, wird man die Sourcen von dieser IDE auch nicht mit gcc compilieren können! Ups,.... und jetzt?
Was bedeutet das eigentlich, etwas gegen etwas anderes linken? Ich lese das oft, aber verstehs nicht
(Und nein, bitte jetzt kein GTK vs. QT-Streit ;-))
Diese externe Bibliothek ist damit Quasi mit dem Programmodul "verlinkt". Während der Laufzeit ("Runtime Linking"), werden alle Bibliotheken die "verlinkt" worden sind automatisch in den Adressbereich der Anwendung geladen. Damit hat man jetzt innerhalb des Programms Zugriff auf die externen Funktionen (und Variablen) (sie befinden sich ja jetzt im Speicherbereich auf den das Programm zugriff hat -Proteced Mode
P.S. Etwas vereinfacht, nicht hauen
an diesem thoraf will ist ein guter missionar verloren gegangen. schade eigentlich. hoffentlich wird er kein inquisitor ...
linus zum grusse
von Redhat, die den Anwendern Linux
verleiden.
Wie oft hatte ich schon den Fall:
Programm laeuft nicht, weil es glibc2.1.2
benotigt es ist aber nur glibc 2.0 auf dem
System, oder Programm laeuft nicht, weil
es mit egcs kompiliert wurde auf dem
System ist aber nur gcc.
Ich moechte es wirklich stark bezweifeln,
dass ein Anwender wirklich Vorteile hat,
dass er die allerneuste Version
irgendeiner Library oder eines
Compilers auf dem System hat.
Von weit fortgeschrittenen Programmen
wie glibc oder gcc werden die neusten
Features von den meisten wahrscheinlich
nie bemerkt.
also weder etwas gegen IXsoft noch gegen RedHat. Zumindest nicht per se.
Aber was auf der ixsoft Seite steht ist schlicht die Unwarheit.
Zum einen ist dieser Compiler ein compiler der von RedHat verändert wurde, ein cvs mit patches. Demnach ist er ein proprietärer d.h. von RedHat gemachter compiler. GCC leistet keinerlei support zu diesem Compiler (nachzulesen auf der GCC liste unter gcc.gnu.org).
Zum anderen ist der compiler nicht binärkompatibel und fertig. Er wird auch nicht wie behauptet mit 3.0 kompatibel sein (libstdc-v3?). Zumindest dann nicht wenn die GCC Entwickler unabhängig von RedHat agieren dürfen. Davon ist erstmal auszugehen.
Die GLIBC ist eine alpha Version die so auch noch nicht existiert. Auf der Verpackung von RedHat steht glibc 2.2 und gcc 2.96. Beides existiert in dieser Form nicht und ist demnach schlicht gelogen.
Ob nun RedHat versucht mit hilfe ihrer momentanen Stellung mehr MArktmacht durch die "inkompatibiliesierung" ihrer Distri durchzusetzen oder ob es nur der Versuch ist einen Schritt nach vorne zu machen, sei dahingestellt.
Auch der offene Brief von Bob Young ist ein Scherz. Wagter der doch zu behaupten "Wer gegen RedHat ist is nur für Microsoft". Das passt ganz gut zu der Vorstellung das RedHat der Erschaffer von FreeSoftware ist.
Steigt da jemandem sein Erfolg zu Kopf ?
Richtig ist:
Es existiert kein gcc-2.96. Das ist lediglich eine RedHat version (vgl. Diskussion LKML sowie GCCML).
Es existiert bisher keine Glibc2.2 wie auf der Verpackung angegeben.
Falsch ist der Vergleich mit dem Kernel oder KDE.
Allerdings liefert auch glaube ich keine Distri einen ungepatchten Standardkernel mit. Aber nun gut.
Aber RailroadT.2. ist gut, und läuft auch unter Debian. Demnach ist die BOX nicht total rausgeschmissenes Geld.
Grüße
Michael.
Nach Aussagen der Entwickler sind alle Patches "Frei" und waren im CVS. Von "proprietär" kann keine Rede sein, also das ist schlicht unwahr. Wenn ich eine Erweiterung für ein beliebiges GPL-Programm machen, meine Änderungen ins CVS stecke und die auch nicht gelöscht werden, dann ist das eine freie Software und keine proprietäre. Punkt.
Der Vergleich zwischen Red Hat und M$ wurde aufgrund verschiedener Artikel in slashdot usw. gezogen, wo genau das Thema diskutiert wurde, daher vermutlich die Stellungnahme von Bob Young ?
Die Kompatiblität betreffend habe ich die Aussage bekommen (die ich mal einfach ungeprüft geglaubt habe), dass gcc3.0 mit gcc 2.95.2 nicht kompatibel sein kann, weil Symbol Mangling (einem C++-Entwickler wird das jetzt was sagen) und die Art und Weise der Benutzung der ELF-sections für exception handling usw. von gcc 2.95.2 einfach es nicht mehr hergaben, die Ansprüche von ANSI C++ zu erfüllen. Vielleicht kann man mit viel Mühe und Verrenkungen einen compat-gcc (ähnlich wie die ganzen compat-glibc und compat-stdc++, wo jetzt langsam keiner mehr durchsteigt) schaffen, aber wozu denn nur ?
Das Problem betrifft ausschließlich C++ und dort wohl vor allem mal wieder libstdc++.
Warum muss ich denn mit Compilern von vor x Jahren unbedingt C++kompatibel sein ? Es wird doch alleine schon aufgrund der library-Abhängigkeiten eh keiner ein Binary von Red Hat 7.0 unter Suse 7.0 zum Laufen bewegen, also muss man sowieso neu compilieren. Wozu die ganze Aufregung dann ?
Meine persönliche Meinung ist die, dass die Erweiterungen von Red Hat absolut notwendig waren, um einen ANSI C++-Compiler zu haben, der sich auch an den Standard hält; gerade bei vielen Entwicklerfirmen ist das absolut wichtig, wie ich aus Erfahrung weiß. Ob gcc 3.0 dazu dann abwärtskompatibel ist, weiß wohl in Wahrheit keiner so recht. Ich werte die Aussage "gcc 3.0 wird inkompatibel zu 2.96" eher als eine Trotzreaktion einer beleidigten (und evt. zu Unrecht übergangenen) Leberwurst anstatt eines objektiven Ansatzes, die eine technische Lösung aller Probleme bringt.
Ich denke, alle sollten sich an einen Tisch setzen (also Red Hat, die genervten gcc-Entwickler, und vielleicht ein paar andere Distributoren wie Suse und Caldera), damit wir zumindest bei so wichtigen Sachen wie gcc, glibc und libstc++ einen einheitlichen Standard haben, wo alle Distributoren drauf aufbauen können, beim Kernel geht das ja auch. Die LSB ist ja sowieso nicht durchzusetzen, aber vielleicht ein etwas kleinerer Standard, der zumindest es ermöglicht in ferner Zukunft einmal binär kompatible Programme zwischen verschiedenen Linux-Distributionen auszutauschen - das ist heute leider nur ein unwirklicher Traum.
Bernd
die Sache ist doch die:
RedHat meint, wie auf der Verpackung von RH7.0 angegeben, es handele sich um gcc-2.96 sowie glibc2.2. Diese existieren in dieser Form nicht.
Die Idee das RedHat versucht eine Inkompatible Version zu stricken um somit Marktvorteile zu erlangen ist auch von namhaften Entwicklern vorgebracht worden (bitte siehe hierzu der Thread auf der LKML sowie auf der GCC-ML).
Es geht mir hierbei nicht darum ob gcc-redhat-2.96 (der compiler meldet sich soweit ich weiss eh als redhat version) mit 2.95.2 kompatibel ist oder nicht oder ob gcc-3.0 mit gcc-2.95.2 kompatibel ist (sehr unwahrscheinlich) sondern darum das von euch gesagt wurde gcc-2.96 hat eine technologie die demnächst in andere Distris einziehen wird.
Das ist schlicht falsch.
Es ist nach derzeitigem Kenntnisstand anzunehmen das Binaries die unter gcc-redhat-2.96 gebacken wurden nicht unter einer distri mit gcc-3.0 libraries laufen werden.
Das ist nicht abzustreiten und nachlesbar auf der GCC-ML.
Die glibc existiert auch so nicth und dort wurden ähnliche Verlautbarungen diskutiert wie bei GCC.
Grüße
Michael.
Wenn sich irgendein Distributor einen CVS-Branch zieht, der weder als pre-release noch in andere Weise für den produktiven Einsatz gedacht(und angeraten) ist, brauch er sich nicht über "Schläge" wundern. Es geht ja hier nicht um irgendein sekundäres Tool, sondern um eines der wichtigsten Systemtools überhaupt. Da muss man sich schon Gefallen lassen, dass bei befürchteten Inkompatibilitäten einige Leute den Mund aufmachen...
Ich hab mir jetzt den ganzen Thread reingezogen und bin mehr als nur erheitert.
Kurz vorweg: Ich surf hier so rum in meiner Mittaxpause, um mich ein wenig auf dem laufenden zu halten, was es so am Sektor gibt, bin aber weit weg davon ein Experte zu sein.
Es muss ja ein Schock gewesen sein, als Red Hat, das ja immer als der quasi unbefleckte "große" kommerzielle Distributor dargestellt wurde(Im Gegensatz zu Suse, das sind ja wohl die Bösen), einfach einen Compiler reinhaut, der kein offizieller Release ist.
*Bumm* Da fallen dann Worte und Sätze von seitens der großen RH Verteidiger (die es offensichtlich selber noch nicht fassen können was da passiert ist), die in einer wissenschaftlichen Diskussion bei jedem Symposium zum Saalverweis führen würden (Und da kenn ich mich aus). Das Aufspielen als beleidigtes Kind, nur weil der Liebling auch Geld verdienen will ist schon ein wenig übertrieben, oder????
Falls es wer noch nicht ganz eingesehen hat. Die Distriutoren am Markt sind nicht Brüder, die sich in einer großen Idee vebunden fühlen,sondern stehen in beinharter Konkurenz zueinander. Und wenn das Geschäft nicht läuft dann gibts in zwei jahren auch RH nicht mehr.
Hier gehts ganz einfach um Kohle. Und wenn RH glaubt das so tun zu müssen, dann sollen sie das doch auch.
So schwer es für die Leute zu akzeptieren ist, die mit Linux seit Jahren auf du und du stehen, aber über den Erfolg von Linux am Desktop -und damit der Distributoren-, entscheiden nicht die wirklich fähigen User, sondern Leute wie ich, die nach 60 Stunden Wochenarbeitszeit ein einfaches System zu Hause wollen, und einfach keine Zeit haben, sich die WEs mit Systemadministration für den Heim-PC zu verbraten. Und diesen Usern, also DAUs wie mir, ist es grundsätzlich absolut egal welche Nummer der Compiler hat und was der so alles kann , Hauptsache ist, ich kann in kurzer Zeit, mit wenig Geld ein System am PC aufsetzen, das funktioniert.
Klarerweise: Für Anwender wie mich, also für die die Distris dann auch zahlen, sind Punkte wie z.B. Kompatibilität verschiedener Distributionsversionen eines Herstellers Kaufentscheidungspunkte. Aber: Wenn die entscheidenden Punkte nicht da sind wird's der Markt bereinigen.
DAS ist ja der Vorteil von Linux. Das nicht nur einer das ist, der uns sagt was Sache ist. Ich brauch keine Office Version Nummer 225, wo die Büroklammern singen können. In hab bei Linux einfach eine Wahl.
Wir alle haben die Auswahl, und keiner von uns muss. Nicht RH nicht SUSE nicht Madrake.
Und noch eins: vielleicht wär es für einige erst mal gut so im Stillen bis zehn zu zählen und ein bisserl nachzudenken bevor sie ihr infantiles Gewäsch in ein Forum schmieren. Obwohl, dann hätt ich vielleicht nicht so viel Spass in meiner Mittaxpause....
mfg Tom
freut mich, dass auch so unbedarfte einfache Menschen wie Du hier auf Deine Kosten kommen.
Grüße
Anon
RH verkauft sogar eine RH7 Standart version ;-)
na die haben halt humor