Universal Binaries

Geschrieben von Beat Rubischon (Link) am Donnerstag, 7. September 2006, 21:22 aus dem wow! dept. Heute stellte ich mir die Frage, wie man auf dem Mac portable Binaries herstellt. Irgendwoher müssen die Universal Binaries ja kommen. MacOS nutzt das Binarie Format Mach-O, welches im Gegensatz zum unter Linux üblichen ELF mehr als ein Format enthalten kann. Aber wie baut man nun solche Binaries? Standardmässig baut der gcc das jeweils aktuelle Format: brubischon@wendy:~$ uname -m i386 brubischon@wendy:~$ gcc -o hello hello.c brubischon@wendy:~$ file hello hello: Mach-O executable i386 beat@majorie:~$ gcc -o hello hello.c beat@majorie:~$ file hello hello: Mach-O executable ppc Wie kriegen wir nun "Kombibinaries" hin? Die Manpage zu gcc meint dazu: -arch arch Compile for the specified target architecture arch. The allowable values are i386, ppc and ppc64. Multiple options work, and direct the compiler to produce ``universal'' binaries including object code for each architecture specified with -arch. This option only works if assembler and libraries are available for each architecture specified. (APPLE ONLY) Also versuchen wir das gleich: brubischon@wendy:~$ gcc -arch i386 -arch ppc -o hello hello.c brubischon@wendy:~$ file hello hello: Mach-O universal binary with 2 architectures hello (for architecture i386): Mach-O executable i386 hello (for architecture ppc): Mach-O executable ppc Easy! Aber können wir das auch übertreiben? brubischon@wendy:~$ gcc -arch x86_64 -arch i386 -arch ppc64 -arch ppc -o hello hello.c brubischon@wendy:~$ file hello hello: Mach-O universal binary with 4 architectures hello (for architecture x86_64): Mach-O 64-bit executable x86_64 hello (for architecture i386): Mach-O executable i386 hello (for architecture ppc64): Mach-O 64-bit executable ppc64 hello (for architecture ppc): Mach-O executable ppc Tut auch. Na dann experimentieren wir weiter. Nicht alle Kombinationen sind möglich - je nach Hardware werden nur Teile der benötigten Libraries mitgeliefert und entsprechend lassen sich auch nur bestimmte Binarieformate bauen. Alle Versuche mit 10.4.7 und XCode 2.4: MacPro: x86_64, i386, ppc64, ppc MacBook: i386, ppc64, ppc G5: ppc64, ppc G4: ppc Rosetta, der ppc Emulator für i386, emuliert jeweils ppc. ppc64 Binaries können nicht ausgeführt werden. G5 lässt 32 und 64 Bit PPC Binaries rennen, G4 nur 32 Bit. Genauso auf der Intel Schine - nur die MacPros haben x86_64 fähige CPUs. Die Grösse der Binaries ist durchaus im Rahmen, auch wenn Konstanten leider nicht nur einmalig abgelegt werden: i386 only: 13340 ppc only: 14212 i386 + ppc: 34692 x86_64, i386, ppc64, ppc: 57921 int sind faszinierenderweise immer 32 Bittig. Im Gegensatz natürlich zu den Pointern, die von 4 auf 8 Bytes wachsen. Vermutlich will Apple damit vielen Portierungsproblemen aus dem Wege gehen. Verglichen mit dem Puff, das wir bei den Linuxdistributionen haben, erscheint mir dieser Weg als absolut geniale Lösung. OK, die Programme werden etwas grösser - aber spielt das heute, wo der eigentliche Programmcode nur sehr wenig Platz im Vergleich zu den vielen Bitmaps, Sounds und anderen Datenfiles einnimmt, überhaupt noch eine Rolle? Ich wäre auf alle Fälle nicht unglücklich, wenn eine typische Linuxdistribution anstelle der verschiedenen Installmedien und /lib vs. /lib64 und dann noch /compat/linux-i386 (gesehen auf Itanium) ganz einfach alles mitbringen würde. Doch wird es für einen Binarieformatwechsel wohl zu spät sein. a.out nach ELF ist doch schon 10 Jahre her und Linuxsysteme sind nicht einfacher geworden. Ach ja, da gab es noch die Idee auf der AS/400. Der Compiler baute nicht ein echtes Binarie, sondern eine Art Bytecode. Zusätzlich zu diesem wurde dann der echte Maschinencode zusammen abgelegt. Als IBM 1994 von ihren eigenen, 48 Bit CPUs auf 64 Bit PPC umstieg, wurde der Maschinencode automatisch aus dem Bytecode neu generiert. Permalink

Das Kleingedruckte: Der Besitzer der folgenden Kommentare ist wer immer sie eingeschickt hat. Wir sind in keiner Weise für sie verantwortlich.