| Available Languages: | Deutsch | English | Français | 日本語 (Nihongo) | 中文 (简) (Simplified Chinese) | |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
GNU Pakete, die Bibliotheken erstellen, nutzen GNU libtool, um die platformspezifischen Prozeduren für das Erstellen und die Installation der Bibliotheken zu verbergen.
Derzeit gibt es vier verschiedene Stränge von libtool:
libtool 1.3: Der häufigste Strang. Die letzte Version dieses Strangs ist 1.3.5. Es kennt Darwin nicht und erzeugt nur statische Bibliotheken. Man kann es an der Präsenz der Dateien ltconfig und ltmain.shim Quelltextbaum erkennen.
libtool 1.4: Lange bearbeitet und vor kurzem als die neue stabile Version heraus gegeben. Dieser Strang hat eine bessere Integration von autoconf. Unglücklicherweise wird dadurch die Migration von 1.3 basierten Paketen nicht trivial. Es unterstützt Darwin 1.3 / Mac OS X 10.0 und benötigt nur geringfügige Patches für Mac OS X 10.1. Man kann es daran erkennen, dass die Datei ltconfig nicht vorkommt. Versionen, die sich als 1.3b oder 1.3d ausgeben, sind tatsächlich Schnappschüsse aus der Entwicklung von 1.4 und mit Vorsicht zu genießen.
Der multi-Sprachen-Zweig: Auch MLB genannt. Diese Version von libtool erhielt parallel die Unterstützung für C++ und Java (mittels gcj). Es wurde in den Hauptzweig der Entwicklung integriert. Aktuelle Versionen unterstützen Darwin 1.3 and Mac OS X 10.0. Den MLB Zweigkann man an der Präsenz der Dateien ltcf-c.sh, ltcf-cxx.sh und ltcf-gcj.sh erkennen.
Der aktuelle Zweig der Entwicklung: Diese Version wird irgendwann als libtool 1.5 heraus gegeben werden. Sie resultiert aus der Integration des MLB Zweigs in 1.4 und unterstützt C, C++ and Java (mittels gcj). Unglücklicherweise, kann man diese Version nicht so einfach von der Version 1.4 unterscheiden. Leider muss man die Versionsnummer in der Datei ltmain.sh überprüfen.
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.
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].
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.
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.
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.
--- 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
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.
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.
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.
CompileScript: echo "nothing to do"
../libtool: test: too many argumentsPassiert dies, enthält configurefolgendes:
archive_cmds='$CC $(test .$module = .yes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts -install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != x0.0 && echo $verstring)'Es folgt ein Patch (Benutzen sie ihn aber vorsichtig, denn manchmal gibt es mehrere Probleme mit libtool. Deshalb ist es besser, diesen Patch von Hand umzusetzen):
diff -Naur gdk-pixbuf-0.16.0/configure gp-new/configure
--- gdk-pixbuf-0.16.0/configure 2002-01-22 20:11:48.000000000 -0500
+++ gp-new/configure 2002-05-10 03:02:44.000000000 -0400
@@ -3338,7 +3338,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='$CC $(test .$module = .yes && echo -bundle || echo
-dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts
-install_name $rpath/$soname $(test -n "$verstring" -a x$verstring !=
x0.0 && echo $verstring)'
+ archive_cmds='$CC $(test .$module = .yes && echo -bundle || echo
-dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts
-install_name $rpath/$soname $tmp_verstring'
# We need to add '_' to the symbols in $export_symbols first
#archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols'
hardcode_direct=yes
diff -Naur gdk-pixbuf-0.16.0/ltmain.sh gp-new/ltmain.sh
--- gdk-pixbuf-0.16.0/ltmain.sh 2002-01-22 20:11:43.000000000 -0500
+++ gp-new/ltmain.sh 2002-05-10 03:04:49.000000000 -0400
@@ -2862,6 +2862,11 @@
if test -n "$export_symbols" && test -n "$archive_expsym_cmds";
then
eval cmds=\"$archive_expsym_cmds\"
else
+ if test "x$verstring" = "x0.0"; then
+ tmp_verstring=
+ else
+ tmp_verstring="$verstring"
+ fi
eval cmds=\"$archive_cmds\"
fi
IFS="${IFS= }"; save_ifs="$IFS"; IFS='~'
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.
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.
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>
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:
| Field | Value |
|---|---|
| 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/opt/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.
/usr/bin/perl ist jetzt perl 5.8.6; die Architektur ist immer noch "darwin-thread-multi-2level".
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.
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 (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2020 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.2 2023/08/04 5:08:13 nieder Exp $