Available Languages: | Deutsch | English | Français | 日本語 (Nihongo) | 中文 (简) (Simplified Chinese) |

Unix Programme nach Darwin und Mac OS X portieren

Dieses Dokument gibt Tipps, wie man ein Unix Programm nach Darwin und Mac OS X portiert. Das meiste trifft sowohl for die Mac OS X Version 10.x.x und "reine" Darwin-Systeme zu. Der Einfachheit halber wird deshalb nur noch Darwin genannt; letztlich ist Mac OS X ja auch ein Obermenge von Darwin. Viele Detailinformationen sind leider nicht mehr aktuell, sondern beziehen sich auf ältere Versionen. Mit einer Aktualisierung sollte aber in der englischen Version begonnen werden.

Contents

1 Grundlagen

1.1 Der Ursprung von Darwin

Darwin ist ein unixoides Betriebsystem das sich aus NeXTStep / OpenStep entwickelte. Der Legende nach entstammt es ursprünglich von 4.4BSD Lite. Das BSD-Erbe ist immer noch spürbar. Tatsächlich wurde Darwin mit Code aus FreeBSD und NetBSD modernisiert.

Darwins kernel basiert auf einer Kombination aus Mach 3.0, BSD und proprietären Funktionen wie die objekt-orientiert Treiberschicht IOKit. Obwohl Mach ursprünglich ein Micro-Kernel-Design hat, ist der darüber liegende BSD-Kernel monolithisch. Die beiden sind jetzt so ineinander verwoben, dass man sie wohl als einen einzigen monolithischen Kernel bezeichnen muss.

Die Tools und Bibliotheken der Nutzerebene von Darwin sind meistens BSD-Varianten, im Gegensatz zu den GNU-Varianten von Linux. Allerdings is Apple nicht ganz so streng wie die anderen BSDs und macht auch häufig Kompromisse. Apple vertreibt beispielsweise sowohl BSD make als auch GNU make, mit GNU make als Voreinstellung.

1.2 Der Compiler und andere Tools

Kurzfassung: Der Compiler is eine gcc Variante, aber installiert als cc. Dementsprechend muss man Makefiles anpassen. Die meisten Pakete erstellen keine gemeinsam genutzten Bibliotheken. Treten Fehler bei Makros auf, setzen sie die Option -no-cpp-precomp.

Langfassung: Die Compiler-Tool-Chain in den Mac OS X Developer Tools ist ein seltsames Ungeheuer. Der Compiler basiert auf der gcc 2.95.2 Suite und hat Modifikationen für die Unterstützung der Sprache Objective C und noch einige Darwin-Spezialitäten. Vom Precompiler (cpp) gibt es zwei Versionen. Die eine ist der Standard-Precompiler (aus gcc 2.95.2), die andere wurde eigens von Apple entwickelt und unterstützt vorkompilierte Header. Die letzte Version ist die Voreinstellung, weil sie schneller ist. Allerdings kompiliert nicht jedes Programm mit Apples Precompiler und man muss die Option -no-cpp-precomp für den Standard-Precompiler einschalten. (Beachte: Die frühere Empfehlung war, die Option -traditional-cpp zu verwenden. Die Semantik dieser Option hat sich aber mit GCC 3 geändert, so dass ihre Verwendung zu Abbrüchen führt. Die Option -no-cpp-precomp hingegen funktioniert sowohl mit den derzeitigen Developer Tools als auch mit zukünftigen Compilers, die auf GCC 3.0 basieren.)

Der Assembler basiert auf gas 1.38, aber der Linker basiert nicht auf GNU Tools. Das ist ein Problem bei der Erstellung von gemeinsam benutzten Bibliotheken, weil GNU-libtools und configure- Skripte den Apple-Linker nicht korrekt aufrufen können.

1.3 Wirtsystem

Kurzfassung: Bricht configure mit dem Meldung 'Can't determine host type' ab, dann kopieren sie die Dateien config.guess und config.sub aus dem Verzeichnis /usr/share/libtool (/usr/libexec für OS X Versionen vor 10.2) in das derzeitige Verzeichnis.

Langfassung: In der GNU-Welt wird ein kanonisches Format für die Angabe von Systemen verwendet, das aus folgenden drei Teilen besteht: CPU-Typ, Hersteller und Betriebsystem. Manchmal folgt noch ein vierter Teil. Dann beschreibt der dritte Teil den Kernel und der vierte Teil das Betriebsystem. Alle Teile werden klein geschrieben und mit Bindestrichen verbunden. Einige Beispiele: i586-pc-linux-gnu, hppa1.1-hp-hpux10.20, sparc-sun-solaris2.6. Für Mac OS X 10.0 lautet die Angabe powerpc-apple-darwin1.3, Mac OS X 10.2 Versionen sind powerpc-apple-darwin6.x.0 und 10.3 powerpc-apple-darwin7.x.0, wobei "x" von der genauen Version abhängt.

Viele Pakete, die autoconf benutzen, wollen wissen, für welches System kompiliert wird. (Randnotiz: für die Unterstützung von Cross-Compiling und Portierung, gibt es tatsächlich 3 Systeme: das Wirtsystem, das Erstellungsystem und das Zielsystem. Meistens sind sie das selbe.) Man kann das Wirtsystem dem configure-Skript übergeben oder man kann es raten lassen.

Das configure-Skript benutzt zwei Partnerskripte, um das Wirtsystem zu bestimmen. config.guess versucht, das Wirtsystem zu bestimmen. config.sub wird benutzt, um das Wirtsystem zu validieren und kanonisch zu machen. Diese Skripte werden als separate Einheiten gepflegt, aber sind in jedem Paket enthalten, das sie benutzt. Bis vor kurzem erkannten diese Skripte Darwin oder Mac OS X nicht. Liegt so ein Paket vor, muss man config.guess und config.sub ersetzen. Glücklicherweise hat Apple funktionierende Versionen im Verzeichnis /usr/share/libtool (/usr/libexec für Mac OS X vor 10.2), so dass man sie einfach von dort kopieren kann.

Wenn sie ein Fink-Paket erstellen, können sie die Felder UpdateConfigGuess und/oder UpdateConfigGuessInDirs in ihrer .info Paketbeschreibung für eine automatische Aktualisierung benutzen.

1.4 Bibliotheken

Kurzfassung: Man kann, muss aber nicht, die Option -lm aus Makefiles entfernen.

Langfassung: Mac OS X hat keine separaten libc, libm, libcurses, libpthread oder ähnliche Bibliotheken. Statt dessen sind sie alle Teil der Systembibliothek libsystem. (In früheren Versionen war es tatsächlich das Framework System.) Darüber hinaus hat Apple entsprechende Symlinks im Verzeichnis /usr/lib angelegt, sodass auch die Option -lm funktioniert. Die einzige Ausnahme ist -lutil. Auf anderen Systemen enthält libutil Funktionen für Pseudoterminals und die Abrechnung von Logins. Diese Funktionen sind in libSystem, aber es gibt einfach keinen Symlink für für ein libutil.dylib.

1.5 Andere Informationsquellen

Eine weitere Quelle für die Portierung ist das Wiki bei MetaPkg Wiki.

Sie können auch die Apple Technical Note TN2071 mit dem Titel "Porting Command Line Unix Tools to Mac OS X" lesen.

2 Gemeinsam benutzter Code

2.1 Gemeinsam benutzte Bibliotheken vs. Ladbare Module

Ein Mach-O Feature erwischt viele ganz kalt: Die strikte Unterscheidung zwischen gemeinsam genutzten Bibliotheken und dynamisch ladbaren Modulen. Auf ELF-Systemen sind die beiden gleich; jeder gemeinsam benutzter Code kann als Bibliothek und als ladbares Mudol genutzt werden. Benutzen sie das Kommando otool -hv some_file, um den Dateityp der Datei some_file heraus zu finden.

Gemeinsam genutzte Mach-O Bibliotheken haben den Dateityp MH_DYLIB und die Dateiendung .dylib. Gegen sie kann ein programm mit den üblichen Linkeroptionen gelinkt werden, also -lfoo für libfoo.dylib. Sie können jedoch nicht als Modul geladen werden. (Randnotiz: Gemeinsam genutzte Bibliotheken können dynamisch über eine API geladen werden. Aber die API unterscheidet sich von der API für Bundles und die Semantik machen sie nutzlos for eine Emulation von dlopen(). Vor allem können gemeinsam genutzte Bibliotheken nicht wieder ausgeladen werden.)

Ladbare Module heißen in Mach-O-Sprech Bundles. Ihr Dateityp ist MH_BUNDLE. Da sich keine Komponente darum kümmert, ist die Dateierweiterung beliebig wählbar. Die Erweiterung .bundle wird von Apple empfohlen, aber die meisten portierten Programme benutzen aus Kompatibilitätsgründen .so. Bundles können dynamisch über die dyld API geladen und wieder ausgeladen werden. Ein Wrapper um diese API emuliert dlopen(). Gegen Bundles kann man nicht linken wie wenn sie gemeinsame genutzte Bibliotheken wären. Aber ein Bundle kann gegen vorhandene, gemeinsam genutzte Bibliotheken gelinkt werden; diese werden dann automatisch mit dem Bundle geladen.

2.2 Versionsnummerierung

Auf Elf-Systemen wird normalerweise die Versionsnummer am Ende des Dateinamens der gemeinsame genutzten Bibliothek nach der Erweiterung angehängt, z. B. libqt.so.2.3.0. Bei Darwin steht die Versionsnummer zwischen Bibliotheksnamen und Erweiterung, also libqt.2.3.0.dylib. Beachten sie, dass sie deshalb beim Linken eine bestimmte Version der Bibliothek angeben können, im obigen Beispiel mit -lqt.2.3.0.

Bei der Erstellung einer gemeinsam genutzten Bibliothek kann man einen Namen vergeben, mit dem zur Laufzeit nach der Bibliothek gesucht werden kann. Dies ist gängige Praxis und ermöglicht es, dass mehrere Haupt-Versionen einer Bibliothek gleichzeitig installiert sind. AUf ELF-Systemen nennt man diesen Namen soname. Unter Darwin kommt dazu, dass man den vollständigen Pfad zu der Bibliothek angeben kann und auch sollte. Die "rpath"-Optionen und das ldconfig/ld.so.cache-System werden dadurch überflüssig. Soll eine Bibliothek benutzt werden, die noch nicht installiert ist, kann man die Umgebungsvariable DYLD_LIBRARY_PATH. Details dazu stehen in der man-Seite von dyld.

Im Gegensatz zu ELF-Systemen erlaubt das Mach-O Format erlaubt auch die tatsächliche Überprüfung der Nebenversion. Jede Mach-O Bibliothek hat zwei Versionsnummern, die "aktuelle" Version und die "kompatible". Beide Nummern bestehen aus drei durch Punkte getrennte Zahlen. z. B. 1.4.2. Die erste Zahl darf nicht Null sein. Die zweite und dritte Zahl können ausgelassen werden und werden dann als Null angenommen. Ist überhaupt keine Zahl angegeben, wird die Version auf 0.0.0 gesetzt. Dies ist quasi ein Joker und passt auf alles.

Die "aktuelle" Version dient nur zur Information; während die "kompatible" Version für die Überprüfung wie folgt verwendet wird: Wird ein Program gelinkt, wird die Versionsinformation der Bibliothek in das Programm kopiert. Wird das Programm ausgeführt, wird die Version im Programm mit der aus der Bibliothek verglichen, die geladen wird. Die Version der Bibliothek muss mit der aus dem Programm übereinstimmen oder höher sein. Ist dies nicht der Fall, bricht dyld das Programm ab und erzeugt einen Laufzeit-Fehler.

2.3 Compiler-Optionen

Auf Darwin ist die Voreinstellung so, dass positionsunabhängiger Code (PIC) erzeugt wird. Tatsächlich ist PowerPC-Code so entworfen, dass er von vorne herein positionsunabhängig ist und damit keine Leistungs- oder Speicherplatz-Nachteil verbunden ist. Man muss deshalb nicht extra eine Option PIC angeben, wenn man eine gemeinsam genutzte Bibliothek oder ein Modul compiliert. Allerdings erlaubt der Linker keine "common" Symbole in gemeinsam genutzten Bibliotheken. Man muss also die Compiler-Option -fno-common angeben.

2.4 Eine gemeinsam genutzte Bibliothek erzeugen

Will man eine gemeinsam genutzte Bibliothek erzeugen, ruft man den Compilertreiber mit der Option -dynamiclib auf. Am besten versteht man dies an einem ausführlichen Beispiel. Es wird eine Bibliotheknamen libfoo aus den Quellcode-Dateien source.c und code.c erzeugt. Die Versionsnummer ist 2.4.5, mit 2 als der Hauptversionsnummer (wegen inkompatiblen Änderungen der API), 4 die Nebenversionsnummer (wegen aufwärtskompatiblen Änderungen der API) und 5 ist die Revisionsnummer für die Behebung von Fehlern (manchmal wird dies auch die "teeny" Revisionsnummer genannt, für vollkompatible Änderungen.). Die Bibliothek hängt von keiner anderen ab und wird in /usr/local/lib installiert.

cc -fno-common -c source.c
cc -fno-common -c code.c
cc -dynamiclib -install_name /usr/local/lib/libfoo.2.dylib \
-compatibility_version 2.4 -current_version 2.4.5 \
-o libfoo.2.4.5.dylib source.o code.o
rm -f libfoo.2.dylib libfoo.dylib
ln -s libfoo.2.4.5.dylib libfoo.2.dylib
ln -s libfoo.2.4.5.dylib libfoo.dylib

Beachten sie bitte, welche Teile der Versionsnummer an welcher Stelle verwendet werden. Linkt man gegen die Bibliothek, verwendet man normalerweise die Option -lfoo, die auf den Symlink libfoo.dylib zugreift. Unabhängig welcher Symlink oder welche tatsächliche Datei angegeben wird, wird der install_name in das Programm eingetragen. Dies bedeutet, dass der der "höhere" (weniger versionsspezifische) Symlink libfoo.dylib nach dem Kompilieren gelöscht werden kann. In einer Aktualisierung der Bibliothek auf dem Niveau der Nebenversion, muss man nur das Ziel des Symlinks libfoo.2.dylib ändern, dass von dynamischen Laufzeitlinker benutzt wird.

2.5 Ein Modul erzeugen

Will man ein ladbares Modul erzeugen, ruft man den Compilertreiber mit der Option -bundle auf. Benutzt das Modul Symbole des Wirtprogramms muss auch die Option -undefined suppress angegeben werden, damit undefinierte Symbole erlaubt sind und auch die Option -flat_namespace, damit der neue Linker ab Mac OS X 10.1 zufrieden ist. Ein ausführliches Beispiel:

cc -fno-common -c source.c
cc -fno-common -c code.c
cc -bundle -flat_namespace -undefined suppress \
-o mymodule.so source.o code.o

Beachten sie, dass es keine Versionsnummerierung gibt. Theoretisch kann dies gemacht werden, in der Praxis ist das aber unbedeutend. Beachten sie außerdem, dass es keine Einschränkungen für den Namen des Bundle gibt. Einige Pakete ziehen es vor, dem Namen ein "lib" voran zu stellen, weil das z. B. auf anderen Systemen verlangt wird. Dies ist alles unkritisch, weil ein Programm den vollständigen Namen benutzt, wenn das Modul geladen wird.

3 GNU libtool

GNU Pakete, die Bibliotheken erstellen, nutzen GNU libtool, um die platformspezifischen Prozeduren für das Erstellen und die Installation der Bibliotheken zu verbergen.

3.1 Die Situation

Derzeit gibt es vier verschiedene Stränge von libtool:

Zusammenfassend ist zu sagen, dass libtool 1.3.x und Pakete, die es nutzen (und das sind die meisten Pakete da draußen), einen Patch benötigen, wenn sie gemeinsam genutzte Bibliotheken auf Darwin erstellen wollen. Apples libtool in Mac OS X ist eine 1.3.5 Version mit Patches, das aber meistens nicht korrekt funktioniert. Christoph Pfisterer verbesserte den Patch mit fest eingestelltem, aber korrektem Pfad und mit voller Versionierung. Die Änderungen worden in die Upstream-Version von libtool übernommen und sind Teil der Version 1.4. Mitglieder des Fink-Teams machen weitere Verbesserungen und geben sie an die Betreuer von libtool weiter. Das Schema für die Versionierung ist über alle Versionen von libtool kompatibel.

Randnotiz: Alle libtool Versionen enthalten die Bibliothek libltdl, die nur funktioniert, wenn auch dlcompat installiert ist. Ab Version 10.3 ist es in Mac OS X enthalten. Für frühere Versionen, kann man die "dlcompat" Familie an Paketen in Fink installieren.

3.2 Der 1.3.5 Patch

Erstellen sie libtool 1.3.5 selbst, müssen sie den folgenden Patch [aktualiisert am 9. 6. 2002] auf den Quellcode von 1.3.5 anwenden und dann die Dateien ltconfig und ltmain.sh löschen. (Sie werden aus den entsprechenden .in Dateien wieder erstellt, wenn man ./configure und make ausführt). Dies wird übrigens im aktuellen Fink-Paket von libtool 1.3.5 automatisch gemacht.

Dies ist allerdings nur die halbe Arbeit - jedes Paket, das libtool verwendet kommt mit seinen eigenen Kopien von ltconfig und ltmain.sh. Man muss also auch diese in jedem paket ersetzen, wenn man es als gemeinsam genutzte Bibliothek erstellen will. Beachte sie bitte, dass dies vor dem Lauf von ./configure erfolgen muss. Zur Vereinfachung können sie die beiden Dateien hier bekommen: ltconfig (98K) und ltmain.sh (110K) [beide aktualisiert am 9. 6. 2002].

3.3 1.4.x reparieren

Es sind mindestens drei Versionen von libtool 1.4.x im Umlauf (1.4.1, 1.4.2 und spätere Schnappschüsse aus der Entwicklung). Sie haben auf Darwin alle Probleme, auch wenn die Details der Fixes unterschiedlich sind. Das "libtool14" Paket aus Fink hat alle notwendigen Änderungen. Sie müssen aber immer noch die Dateien ltmain.sh und configure in ihren Paketen ersetzen, damit sie erstellt werden können.

  1. Das Problem mit flat_namespace : Dieses Problem tritt nur auf, wenn sie libtool auf Mac OS X 10.1 oder später verwenden. Libtool versucht da die Option -undefined suppress zu verwenden, um nicht deklarierte Symbole zu erlauben. Dies kollidiert aber mit der Option -flat_namespace. Beginnend mit 10.1 funktioniert dies nicht mehr. Ein typischer Patch sieht so aus:
    diff -Naur gdk-pixbuf-0.16.0.old/configure gdk-pixbuf-0.16.0.new/configure
    --- gdk-pixbuf-0.16.0.old/configure	Wed Jan 23 10:11:48 2002
    +++ gdk-pixbuf-0.16.0.new/configure	Thu Jan 31 03:19:54 2002
    @@ -3334,7 +3334,7 @@
    ;;
    
    darwin* | rhapsody*)
    -    allow_undefined_flag='-undefined suppress'
    +    allow_undefined_flag='-flat_namespace -undefined suppress'
    # FIXME: Relying on posixy $() will cause problems for
    #        cross-compilation, but unfortunately the echo tests do not
    #        yet detect zsh echo's removal of \ escapes.
    
  2. Das Problem mit ladbaren Modulen: Dieses Problem entsteht durch nicht-Standard Verhalten von zsh (Das ist die voreingestellte Shell in 10.0 und 10.1; mit 10.2 ist es bash). Die Behandlung von Anführungszeichen verhindert, dass unter zsh ladbare Module korrekt erstellt werden. Statt dessen werden gemeinsam genutzte Bibliotheken erstellt (im Gegensatz zu Linux sind diese unter Darwin völlig unterschiedlich). Ein typischer Fix ist (kann aber nicht unmodifiziert verwendet werden):
    diff -Naur gnome-core-1.4.0.6.old/configure gnome-core-1.4.0.6.new/configure
    --- gnome-core-1.4.0.6.old/configure	Sun Jan 27 08:19:48 2002
    +++ gnome-core-1.4.0.6.new/configure	Fri Feb  8 01:10:21 2002
    @@ -4020,7 +4020,7 @@
    # FIXME: Relying on posixy $() will cause problems for
    #        cross-compilation, but unfortunately the echo tests do not
    #        yet detect zsh echo's removal of \ escapes.
    -    archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle || echo -dynamiclib) ...'
    +    archive_cmds='$nonopt $(test x$module = xyes && echo -bundle || echo -dynamiclib) ...'
    # We need to add '_' to the symbols in $export_symbols first
    #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols'
    hardcode_direct=yes
    

    Diese Problem ist in einigen post-1.4.2 Versionen von libtool behoben.

  3. Das Problem der convenience-Bibliothek: Unter bestimmten Bedingungen, scheitert libtool convenience-Bibliotheken zu linken und berichtet "multiple definitions" Fehler. Anscheinenend wird dies durch einen grundlegenden Fehler von libtool verursacht. Vorerst gibt es folgende Lösung, auch wenn die nicht das tatsächliche Problem löst, sondern nur die Symptome beseitigt (Dank an Dave Vasilevsky):
    --- ltmain.sh.old       2002-04-27 00:01:23.000000000 -0400
    +++ ltmain.sh   2002-04-27 00:01:45.000000000 -0400
    @@ -2894,7 +2894,18 @@
    if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then
    eval cmds=\"$archive_expsym_cmds\"
    else
    +         save_deplibs="$deplibs"
    +         for conv in $convenience; do
    +       tmp_deplibs=
    +       for test_deplib in $deplibs; do
    +         if test "$test_deplib" != "$conv"; then
    +           tmp_deplibs="$tmp_deplibs $test_deplib"
    +         fi
    +       done
    +       deplibs="$tmp_deplibs"
    +         done
    eval cmds=\"$archive_cmds\"
    +         deplibs="$save_deplibs"
    fi
    save_ifs="$IFS"; IFS='~'
    for cmd in $cmds; do
    
  4. Das Problem mit DESTDIR: Bestimmte Pakete, die DESTDIR setzen und libtool 1.4.2 nutzen haben Probleme beim relinken. Die Probleme werden in folgenden Emails diskutiert:

    http://mail.gnu.org/archive/html/libtool/2002-04/msg00019.html

    http://mail.gnu.org/archive/html/libtool/2002-04/msg00021.html

    http://mail.gnu.org/archive/html/libtool/2002-04/msg00025.html,

    and a patch for the problem is discussed in:

    http://mail.gnu.org/archive/html/libtool/2002-04/msg00043.html.

3.4 Weitere Notizen

Weitere Information über libtool und seine Funktionsweise gibt es auf der libtool Homepage.

Randnotiz: Apples Developer Tools enthalten auch ein Program namens libtool, das vom Compiler benutzt wird, um gemeinsam genutzte Bibliotheken zu erstellen. Dieses hat jedoch überhaupt keinen Bezug zu GNU libtool. Das GNU libtool von Apple ist statt dessen als glibtool installiert. Seine Verwendung kann man erreichen, indem man GNU libtool mit --program-transform-name=s/libtool/glibtool/ konfiguriert.

4 Vorbereitungen für 10.2

4.1 Die Shell bash

Der Übergang von 10.0 nach OS X 10.1 war für Fink relativ leicht, nicht zuletzt weil man für einige der Änderungen im voraus geplant hatte. Das ist auch für die nächsten Übergänge geplant, aber viele Details sind noch nicht bekannt.

So weit wir wissen, wird mit OS X 10.2 zsh von bash abgelöst, um die Funktionalität von /bin/sh zu erhalten. Das wirkt sich mindestens an drei Stellen für Fink aus.

4.2 Der gcc3 Compiler

Mac OS X 10.2 nutzt den Compiler gcc3.

Einige Paket mit ladbaren Modulen, die libtool benutzen, brechen mit einem install-name Fehler ab, weil libtool die Option -install_name auch zusammen mit der Option -bundle übergibt, wo sie nicht zwingend benötigt wird. Vom compiler gcc2 wurde dieses Verhalten akzeptiert, aber nicht vom Compiler gcc3. Die Lösung des Problems ist hier beschrieben. Beachte sie, dass sie diesen Patch mit libtool-1.3.5 nicht benötigen (Wenn sie z. B. das Feld UpdateLibtool: True gesetzt haben.), weil er bereits in die von Fink revidierte Version der Datei ltconfig enthalten ist (auch als Vorabversion von fink erhältlich):

Ein anderes Problem mit dem Compiler gcc3 is eine Inkompatibilität der C++ ABIs von gcc2 und gcc3. In der Praxis bedeutet das, dass mit gcc3 kompilierte C++ Programme keine Bibliotheken linken können, die mit gcc2 kompiliert wurden.

5 Vorbereitungen für 10.3

5.1 Perl

In OS X 10.2, /usr/bin/perl war perl 5.6.0 und der die Architektur hieß "darwin". In OS X 10.3, /usr/bin/perl wurde auf perl 5.8.1 aktualisiert und die Architektur in "darwin-thread-multi-2level" umbenannt. Diese Änderungen sollten bei der normalen Verwendung von perl bei der Erstellungen von Paketen keine Probleme verursachen, weil jede Version von perl weiß, wo sie ihre eigenen Modulen findet. Paketbetreuer, die diesen Regeln Perl Modules packaging policy folgen und auch der Dokumentation zu CompileScript und InstallScript folgen, haben bereits alles richtig aufgesetzt.

5.2 Neue Definitionen von Symbolen

Beginnend mit Mac OS X 10.3 gibt es jetzt eine vollständige Definition des Typs socklen_t. FÜgen sie folgendes für eine Typdefinition zu ihrem Programm hinzu:

#include <sys/types.h>
#include <sys/socket.h>

5.3 Neue Systembibliotheken

Mac OS X 10.3 enthält einige neue Bibliotheken, die vorher nicht vorhanden waren und deshalb bisher als Fink-Pakete zur Verfügung gestellt wurden:

FieldValue
libpoll

Die Dateien /usr/lib/libpoll.dylib und /usr/include/poll.h sind jetzt in Mac OS X enthalten, aber die Implementation der Bibliothek ist unvollständig. Reicht die Bibliothek dennoch für ihre Zwecke aus, können sie die Abhängigkeiten in von den Fink-Paketen "libpoll" und "libpoll-shlibs" entfernen. Der Code der Bibliotheken wurde in libSystem gepackt, das automatisch gelinkt wird. Deshalb wird -lpoll nicht mehr benötigt, wenn sie die OS X Implementation benutzen wollen. Beachten sie, dass OS X die Datei libpoll.dylib enthält, so dass die Option -lpoll zu unterschiedlichen Ergebnissen führen kann, je nachdem ob das Fink Paket "libpoll" installiert ist oder nicht.

libdl

Die Dateien /usr/lib/libdl.dylib und /usr/include/dlfcn.h sind jetzt vorhanden und man sollte die Abhängigkeiten von den Fink-Paketen "dlcompat", "dlcompat-dev" und "dlcompat-shlibs" nicht mehr benötigen. Die Code der Bibliotheken wurde in libSystem gepackt, das automatisch gelinkt wird. Deshalb wird -ldl nicht mehr benötigt, wenn sie die OS X Implementation benutzen wollen (Es macht aber nichts, wenn sie es dennoch angeben).

GNU getopt

Diese Bibliothek wurde einschließlich der Funktion getopt_long() in libSystem und /usr/include/getopt.h realisiert, so dass man die Fink-Pakete "libgnugetopt" und "libgnugetopt-shlibs" nicht mehr als Abhängigkeiten benötigt. LibSystem wird automatisch gelinkt und /usr/include wird automatisch durchsucht, so dass sie die Optionen -lgnugetopt und -I/sw/include/gnugetopt nicht mehr benötigen. Sie wurden bisher verwendet, um "libgnugetopt" aus Fink zu verwenden.

Migrieren sie ein Paket nach OS X 10.3, versuchen sie diese veralteten Abhängigkeiten zu entfernen, denn diese Pakete werden vermutlich in der Zukunft entfernt. Dies bedeutet, dass sie ja nach Baum verschiedene Paketbeschreibungen anlegen müssen. Beachten sie auch, dass die Revision immer erhöht werden muss, wenn sie Änderungen in einem Paket vornehmen. Dadurch ist es für einen Nutzer, der von OS X 10.2 auf 10.3 aktualisiert, so, dass er ein 10.3-spezifissches Paket als ein "neueres" als sein vorhandenes für 10.2 sehen wird. Es ist Konvention, dass die Revision bei Änderungen im Zusammenhang mit einer Migration zu einem höheren Baum um 10 erhöht wird damit noch Platz für zukünftige Aktualisierungen im niedrigeren Baum ist.

Beim Test eines migirierten Pakets müssen sie darauf achten, dass sie alle Pakete löschen, deren BuildDepends sie entfernt haben. Andernfalls kann es sein, dass der Compiler immer noch die Bibliotheken aus Fink verlinkt.

6 Vorbereitungen für 10.4

6.1 Perl

/usr/bin/perl ist jetzt perl 5.8.6; die Architektur ist immer noch "darwin-thread-multi-2level".

6.2 Neue Definitionen von Symbolen

Unter Mac OS X 10.4 hat sich der Typ vieler Symbole geändert. Haben sie früher einen Typ explizit gesetzt, indem sie z. B. socklen_t als int definierten, dann ist das möglicherweise nicht mehr korrekt.

6.3 Neue Systembibliotheken

Die Funktion poll() war in Mac OS X 10.3 tatsächlich eine emulation und mittels select() implementiert. In Mac OS X 10.4 ist poll() eine echte Funktion, die im Kernel implementiert ist. Sie funktioniert aber nicht mit Sockets. Es ist deshalb besser, die Funktion poll() des Systems komplett zu ignorieren. Das Paket glib2 aus Fink wurde gepatched und enthält eine voll funktionsfähige Emulation. Deshalb ist es bessser, die poll-ähnlichen Funktionen aus dieser Bibliothek zu verwenden.


Copyright Notice

Copyright (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2015 The Fink Project. You may distribute this document in print for private purposes, provided the document and this copyright notice remain complete and unmodified. Any commercial reproduction and any online publication requires the explicit consent of the author.


Generated from $Fink: porting.de.xml,v 1.10 2014/10/25 09:21:47 Nachteule Exp $