Alres Thema, immer wieder aktuell. Ich hoffe, daß es nicht schon 1.000 Threads dazu gibt, habe jedenfalls keine gefunden und lege mal los.
Das Folgend Beschriebene ist nicht nur für Besitzer alter Rechner, sondern auch für Softwareentwickler gedacht. Ich will über meine Erfahrungen und Einsichten schreiben, und bitte um Feedback und z.B. einen (funktionierenden !) Patch für "Gimp", sofern es einen gibt.
Der K6 von AMD hatte etwa zum Millennium seinen besonderen Charme als schnellste CPU für die damals sehr beliebten Sockel 7 Mainboards. Der K6 startete die "Aera Athlon", während der AMD auch noch mit dem Start der 64 Bit Aera die Nase vorn hatte. Erst ab dem Pentium IV konnte Intel wieder ernsthaft aufholen. In meinem Umfeld laufen nach wie vor 2 Stück K6 Rechner (mit ALI bzw. VIA Chipsätzen) und mit angepaßtem SuSE 11.2.
Der K6 (ab 350 MHz) gilt bis Heute als instabil. So stürzt z.B. Windows 95 schon beim Boot ab. Viele in Pascal programmierte DOS Shareware (z.B. Geddy CAD 6.0) verweigerte ab 250 MHz ebenso die Zusammenarbeit, was in der Szene unsäglichen Schaden anrichtete. Windows 98 galt von Natur aus als Instabil, und war das auf K6 CPU um so mehr. Befeuert mit OS/2 (Warp oder Merlin) oder einem sauber konfigurierten Linux lief die Sache aber durchaus steinstabil. Auch Windows 2000 lief damals ebenfalls auffallend stabil auf K6 CPU, es gab leider kaum Treiber. Windows XP (2003) allerdings wurde auf K6 Rechnern schon bald zur Katastrophe.
Die Linux Probleme mit AMD begannen vor etwa 10 Jahren (um 2005). Sie brachten damals erheblichen Imageverlust für AMD, weil Linux das erste populäre Betriebssyastem war, das für Athlon 64 Bit verfügbar war. Wer mit seinem K6 unter Linux schlechte Erfahrungen gemacht hatte, lehnte den Kauf eines Athlon 64 ab, weil man gleiches befürchtete.
Die erste populäre Linux Anwendung, die auf K6 Plattformen ernsthafte Probleme bereitete, war die allseits beliebte Bildbearbeitungssoftware "GIMP". Ich hatte damals SuSE auf der Platte. Bei der Umstellung auf 10.0 (2005, Rechner damals erst 4 Jahre alt) stüzte GIMP 2.2.8 schon beim "Splash Screen" erbarmungslos mit "ungültiger Maschinenbefehl" ab. Das war gleichzeitig eine unsägliche Blamage für den damals neuen SuSE Eigner Novell, dem eigentlich gut aufgemachten und insgesamt recht stabilen 10er SuSE blieb der Erfolg verwehrt. Bei Debian / Ubuntu ist das Problem ab dem Gimp 2.2.6 bekannt.
Die Programmierung (Quelltext, Source) von Gimp ist offen und gilt als einwandfrei. Falls man die Installation (Festplatte bei mir im Wechslerahmen) in einen Intel Rechner gab, oder eine Intel CPU in seinen Sockel 7 steckte, lief Gimp plötzlich eisern stabil. Anscheinend ist auch das Binary einwandfrei.
Die Angelgenheit schaute aus wie ein Hardwareproblem.
Was auch immer die Gimp / Gnome / GTK Programmierer bewegt hatte, eine Software zu entwickeln, welche, geschickt versteckt, decidiert die Intel CPU bevorzugt, ist bis Heute nicht geklärt. Angeblich ab Gimp 2.3.8 war ein Patch eingebaut, der das Problem abstellen soll. Wirklich stabil wurde Gimp allerdings nicht mehr. Bei Version Gimp 2.6 unter SuSE 11.2 (2009) und nur auf AMD stürzte u.a. das gesamte "Farben" Menü ab. Das aktuelle Debian "Jessie" (und sicherlich auch SuSE) sind insgesamt auf K6 CPU unnötig arg instabil geworden, das Problem hat sich leider eher noch ausgeweitet. Die entsprechenden Threads & Bugreporte quer durch alle Linux Distributuionen sind mittlerweile rund 10 Jahre alt und stehen sämtlich "ungelöst" im Netz. Es wurden unzählige Legenden zur thermischen Instabilität des K6 und seiner Inkompatibilität zum gcc Compiler verbreitet, doch bekommt man auch einen K6 mit etwas Untertakten "vollgasfest", und auch ein mit gcc selbst compilierter eigener Kernel ist steinstabil. Das ist ein Gimp / GTK Problem.
Aber auch selbst compilieren half nicht. Bei Versionen bis einschließlich 2.3.0 lief zumindest "./configure" noch fehlerfrei durch, Gimp ab 2.3.1 hatte bereits ab "./configure" erhebliche Bauchschmerzen mit der Python Erweiterung. Diese alten Gimp Versionen sind jedoch leider inkompatibel zum gcc in Version 4. Die Compilierung bricht mit einem ASM Fehler ab. Die einzige "offizielle" Gimp Version, welche sich (ohne Python) in SuSE 11.2 mit "Bordmitteln" fehlerfrei durchcompilieren läßt, ist Gimp 2.7.0. Der Compiler läuft fehlerfrei durch, das Binary jedoch hat die gleichen Probleme wie das 2.6.7 von SuSE. Auch Gimp 2.7.0 stürzt auf K6 Rechnern nach wie vor mit "ungültiger Maschinenbefehl" ab, sobald auch nur ein Punkt aus dem "Farben" Menü angeklicht wird, ist auch ansonsten arg instabil. Wer bereit war, auch "Babl & Gegl" selbst zu compilieren, konnte sich bis auf Gimp 2.7.1 steigern. Diese Version hatte die gleichen Probleme. Inoffizielle weitere SuSE Compilations (bis etwa 2011) ließen sich nicht mehr ohne erhebliche Eingriffe in das Python Subsystem (u.a. essentielle Skripte, z.B. zur Druckerkonfiguration erforderlich) installieren. Sie gelten durchwegs als arg instabil auf der K6 Plattform.
Von Anfang an stand die Gegl Bibliothek in Verdacht. Denn mit der Einführung von Gegl wurde Gimp instabil. Ich habe mir auch hier reichlich Mühe gemacht, und mal herumgehackt. Das sehr schöne "./autogen.sh" läuft mit SuSE 11.2 "Bordmitteln" für die Gegl Versionen 0.1.0 sowie 0.1.2 fehlerfrei durch. Damit kommt man in Sachen Gimp bis 2.7.1, allerdings mit bekannten Instabilitäten.
Gegl geht auf AMD K6 CPU tatsächlich nicht compilieren, der Fehler scheint gefunden. Die Übersetzung mit "make" bricht mit Fehlermeldung "ungültiger Maschinenbefehl" ab, was oft als drastischer Hinweis gewertet wurde. Geht man der Sache nach, so stürzt der Compiler ab bei dem Versuch, ein Bild aus "/docs/gallery" einzulinken. Offensichtlich existiert in den komprimierten Bildern (JPG, PNG, SVG) ein (wohl mehr oder weniger) "zufälliger" Code, welchen die CPU später als "ungültiger Maschinenbefehl" interpretiert und mit Absturz quittiert. Das funktioniert auch mit 100% einwandfreien Quelltexten und einem 100% einwandfreien Compiler. Die "Schadsoftware", die hier gezielt AMD CPU zum Absturz bringt, ist geschickt in den eingebundenen Bildern versteckt. Der "Trick" ist schon seit den BBS Urzeiten bekannt. Das "Textvirus" wurde, scheinbar unsichtbar, damals oft als "Steuerzeichen" getarnt, an den Anfang von scheinbar völlig harmlosen ANSI Begleittexten gestellt. Durch die CPU gejagt bleibt es "binär" unsichtbar, angezeigt wurde nur der nachfolgende Text, der Rest wurde von CPU (oder GPU) "verschluckt" und zeigte als kleines Assemblerprogramm seine Wirkung. Man muß sowas leider auf Assemblerebene debuggen. Als Hack Around bietet sich an, das Bilderverzeichnis per Kommentarzeichen auszublenden, es fehlen dann im kompilierten Binary ein paar Bilder in der Dokumentation. Als weitere Probleme der "/docs/Makefile.am" Vorlage betrifft das Einlinken von HTML ohne die vorherige Definition von HTML, was ebenfalls zum Absturz führt. Ein "gehacktes" Makefile, das (bei benannten Leistungsmängeln des resultierenden Binary) zumindest fehlerfrei compilieren geht, binde ich im Anhang mit ein.
Leider führt auch eine "fehlerfrei" durchkompilierte Gegl Bibliothek nicht zur Stabilisierung. Zwar kann man hinterher (bei selbst compiliertem Gimp 2.7.0) tatsächlich die eine oder andere Gegl Funktion aufrufen, ohne daß Gimp sofort abschmiert, doch bleibt z.B. das "Farben" Menü unbeeindruckt instabil.
Ich weiß nicht, wie oft ich versucht habe, den Gimp für K6 zu compilieren, ich habe es leider nicht stabil bekommen. Geht es um Gimp, so "füttere" ich meinen K6 Rechner nach wie vor mit einer Wechselplatte mit SuSE 9.1 und Gimp 2.2.0. (Stand 2003) Das ist steinalt, aber funktioniert. Ich freue mich auf qualifizierte (erprobte) Anregungen und Diskussion. Ich bitte zu bedenken, daß die vollständige Compilierung von Gimp 2.7.0 auf dieser Maschine etwa 5 Stunden (ohne Einrichten) dauert, ich kann also schon aus Zeitgründen nicht jeden Tag dreimal zum Test herumcompilieren, um wirklich jeden "blöden" Tip auszuprobieren. Andererseits ist das Problem ja nun nicht gerade neu, aber halt nach wie vor ungelöst. Nach nun 10 Jahren könnte man es halt bitteschön mal angehen.
Das größte Problem, soweit ich das heraushacken konnte, betrifft in die Binaries eingebundene Bilder in komprimierten Dateiformaten. Dabei entsteht (wohl mehr oder weniger) "zufällige Schadsoftware", welche, durch den Prozessor gejagt, später die CPU zum Absturz bringt. Möglicherweise ist die AMD K6 CPU tatsächlich empfindlicher gegen "schmutzigen Code" als z.B. ein Intel Pentium IV es ist. Ihren besonderen Charme hat die Maschine bei mir als Software Tester gewonnen. Was auf dem K6 stabil ist, läuft (meist) überall.
So, als Anhang hier noch mein "/gegl-GEGL_0_1_2/docs/Makefile.am" in "gehackter" Version, welche auch auf einem AMD K6 zumindest fehlerfrei compilieren geht:
39081
Laß uns Freunde bleiben