Zunächst Linux auf verschiedenen Hardwareplattformen kann nie zueinander binärkompatibel sein, d.h. ein Programm das für eine CPU-Plattform (z.B. x86-Linux) kompiliert wurde, wird nie auf einer anderen CPU-Plattform (z.B. ppc-Linux) laufen. Was aber theoretisch gegeben sein sollte, ist die Kompatibilität auf Sourcecode-Ebene, d.h. man sollte in der Lage sein sich aus den Sourcen eine für seine Plattform passendes Binary zu kompilieren. Leider trifft dies auch nicht immer zu. Und dafür gibt es mehrere Gründe:
Assembler Manche Sourcen sind teilweise in Assembler geschrieben, insbesondere an geschwindigkeitskritischen Stellen. Beispielweise sind beim "Kryptofilesystem" ppdd die Verschlüsselung Algorithmen in Assembler geschrieben. Hier muss man also den entsprechenden Algorithmus in PPC-Assembler oder zur Not in C neu implementieren.
Unterschiede in den Bibliotheksversionen
Das wichtigste Beispiel hierfür sind wohl die verschiedenen Versionen der Standard-C-Bibliothek.
Lange Zeit nutzte Linux die libc5.xx als Standard-C-Bibliothek.
Dann wurde der Übergang auf die glibc2.0 propagiert und langsam auch vollzogen.
Die Mac-Linuxe sind daher gleich auf den glibc2.0-Zug aufgesprungen.
Da die glibc zu Beginn der Mac-Linux-Geschichte noch nicht fertig war, begnügte man sich
mit der Vorabversion 1.99. Dabei ist amn dann bis LinuxPPC R4, bzw. MkLinux DR 3 hängen geblieben,
obwohl diese Version außerhalb der Entwicklergemeindeauf x86-Linux nie
benutzt wurde. Mit YDL 1.0 und LinuxPPC 99 (und demnächst mit MkLinux R1)
gab es dann einen Sprung gleich auf die glibc2.1 (Inzwischen war die Entwicklung bei x86-Linux
an dem Mac-Linux vorbeigezogen).
Wenn sich nun eine Software auf spezielle Eigenschaften
einer dieser Versionen verlässt ist es eben Essig, bzw. man muss selbst Hand anlegen.
Solche Probleme können auch zwischen verschiedener x86-Linux-Distributionen auftreten.
Zugriff auf interne undokumentierte Strukturen
Gerade bei Linux-Komerz-Software greifen die Entwickler gerne auf
interne Strukturen der Bibliotheken zu. Diese
können sich aber schon innerhalb der x86-Linux von Distribution zu Distribution unterscheinden.
So brauchte z.B. SuSE-Linux eine eigens dafür
kompilierte StarOffice 5.0 Version (bei 5.1 ist wohl alles wieder im Lot).
Unterschiedliche Bug-Empfindlichkeiten
Und es gibt immer bugs in einem Programm,
die je nach CPU- und OS-Plattform mal auftreten und mal nicht.
Wenn man nciht selbst auf verschiedenen (UNIX-)Plattformen programmiert hat,
wird einem dies absurd erscheinen. Es stimmt aber trotzdem:
Zum Beispiel kann eine nicht explizit initialisierte Varibable
je nach OS, CPU und Optimierungslevel beim Compileren mal auf
0 gesetzt sein und mal auf einen Zufallswert. Wenn das Programm sich darauf verlässt,
dass diese Variable den Wert 0 hat, kann es auf der als zweites genannten Plattform abstürzen,
ohne das der Bug auf der erstgenannten jemals bemerkt würde.
Arbeits- und Zeitaufwand
Bei Kommerzsoftware gilt natürrlich auch: es kostet Arbeit und damit
Zeit und vor allem Geld. Es muss ein
entsprechender Rechner angeschafft und gewartet werden.
Man muss den Compiler einmal extra anschmeissen und damit
rechnen Bugs zu finden, die bisher nicht in Erscheinung getreten sind (s.o.).
Auch wenn sie auf den anderen Plattformen vielleicht nie relevant würden,
hinterlässt dies bei einem ordentlichen Entwickler ein ungutes Gefühl.
Es könnte ja ,....