| Available Languages: | Deutsch | English | Français | 日本語 (Nihongo) | 中文 (简) (Simplified Chinese) | |
Ce document contient quelques conseils pour réaliser le portage d'applications Unix vers Darwin et Mac OS X. Ces informations s'appliquent aux systèmes d'exploitation Mac OS X versions 10.x.x et Darwin "pur". Nous ferons référence aux deux systèmes sous le nom de Darwin, puisque Mac OS X est, en fait, un sur-ensemble de Darwin.
Darwin est un système d'exploitation de type Unix qui est issu de NeXTStep/OpenStep. La tradition veut qu'il fut initialement créé à partir de la version 4.4BSD Lite. L'héritage du système BSD est encore apparent ; en fait Darwin a été modernisé, récemment, avec du code FreeBSD et NetBSD.
Le noyau Darwin est construit sur une combinaison de Mach 3.0 et de BSD, ainsi que sur des fonctionnalités propriétaires comme la couche de pilote orientée objet IOKit. Bien que Mach ait, au départ, une structure de micro-noyau, le noyau BSD qui est installé au-dessus est monolithique, et les deux sont si imbriqués maintenant que l'on peut considérer l'ensemble comme un seul noyau monolithique.
Les outils utilisateur et les librairies fournies avec Darwin sont, pour la plupart, issues de BSD par opposition à ceux de Linux qui sont des outils GNU. Toutefois, Apple n'est pas aussi strict que d'autres systèmes BSD et a fait des compromis utiles. Par exemple, Apple fournit aussi bien make BSD que make GNU, la commande make de GNU étant celle installée par défaut.
En bref : le compilateur est un dérivé de gcc, mais installé en tant que cc ; vous pouvez avoir besoin de faire des rustines sur des Makefiles. La plupart des paquets ne construiront pas de librairies partagées. Si vous voyez des erreurs relatives à des macros, utilisez l'option -no-cpp-precomp.
En détail : le chaînage des outils de compilation des Mac OS X Developer Tools est une drôle de bête. Le compilateur est basé sur la suite gcc 2.95.2, avec des modifications pour gérer le langage Objective C et quelques bizarreries de Darwin. Le préprocesseur (cpp) existe en deux versions. L'une correspond au précompilateur standard (issu de gcc 2.95.2), l'autre est un précompilateur spécial écrit par Apple, avec gestion des headers précompilés. Ce dernier est celui utilisé par défaut, car il est plus rapide. Toutefois, certains codes ne compilent pas avec le précompilateur Apple, c'est pourquoi vous devez vous servir de l'option -no-cpp-precomp pour utiliser le précompilateur standard. (Note : je recommandais, auparavant, l'option -traditional-cpp. La sémantique de cette option a légèrement changé avec GCC 3, empêchant la compilation de la plupart des paquets qui l'utilise. -no-cpp-precomp a l'effet désiré aussi bien sur les Developer Tools actuels que sur les futurs compilateurs basés sur GCC 3).
L'assembleur est soi-disant basé sur gas 1.38. L'éditeur de liens n'est pas basé sur les outils GNU. Cela pose problème lorsqu'on construit des librairies partagées, étant donné que GNU libtool et les scripts de configuration qu'il génère ne savent pas comment se comporter avec l'éditeur de liens d'Apple.
En bref : si configure échoue avec un message d'erreur 'Can't determine host type' - Impossible de déterminer le type d'hôte, copiez config.guess et config.sub, situés dans /usr/share/libtool (/usr/libexec pour des versions antérieures au 10.2), dans le répertoire courant.
En détail : le monde GNU utilise un format canonique pour spécifier les types de systèmes. Ce format comporte trois parties : le type de la cpu, le fabricant et le système d'exploitation. Parfois, une quatrième partie est ajoutée - dans ce cas la troisième partie indique le noyau, tandis que la quatrième indique l'OS. Toutes les parties sont en minuscules et sont concaténées en utilisant des tirets. Quelques exemples : i586-pc-linux-gnu, hppa1.1-hp-hpux10.20, sparc-sun-solaris2.6. Le type d'hôte pour Mac OS X 10.0 est powerpc-apple-darwin1.3. Pour Mac OS X 10.2, le type d'hôte a la forme powerpc-apple-darwin6.x.0, et pour Mac OS X 10.3 la forme powerpc-apple-darwin7.x.0, où "x" dépend de la version exacte du système opératoire.
De nombreux paquets utilisant autoconf doivent connaître le type d'hôte du système sur lesquels ils sont compilés. (Note subsidiaire : il existe, en fait, trois types - hôte, build et cible - pour pouvoir gérer la compilation croisée et le portage. En général, ils sont tous les trois identiques). Vous pouvez soit passer le type d'hôte en paramètre au script configure, soit laisser le script déterminer le type d'hôte.
Le script configure utilise deux autres scripts pour déterminer les types d'hôtes. config.guess essaie de deviner le type d'hôte, config.sub est utilisé pour valider et donner une forme canonique au type d'hôte. Ces scripts sont maintenus en tant qu'entités séparées, mais sont inclus dans tout paquet qui les utilise. Naguère encore, ces scripts ignoraient totalement Darwin ou Mac OS X. Si vous êtes en présence d'un paquet qui ne reconnaît pas Darwin, vous devez remplacer les config.guess et config.sub inclus dans le paquet. Heureusement, Apple a placé des versions fonctionnelles de ces scripts dans /usr/share/libtool (/usr/libexec pour pre-10.2 OS), il vous suffit donc de les recopier à partir de là.
Si vous construisez un paquet Fink, vous pouvez utiliser les champs UpdateConfigGuess et / ou UpdateConfigGuessInDirs dans le fichier .info de description du paquet, de façon à ce que la mise à jour soit automatique.
En bref : vous pouvez tranquillement supprimer -lm des Makefiles, mais vous n'y êtes pas obligé.
En détail : Mac OS X ne possède pas de librairies libc, libm, libcurses, libpthread, etc... séparées. Elles font toutes parties intégrantes de la librairie système, libSystem. (Dans les versions antérieures, c'était la structure System). Toutefois, Apple a placé des liens symboliques dans /usr/lib, donc l'édition de liens avec -lm fonctionne. La seule exception est -lutil. Sur d'autres systèmes, libutil contient des fonctions relatives aux pseudo-terminaux et à la gestion des ouvertures de connexion. Ces fonctions font partie de libSystem, mais il n'y a pas de lien symbolique pour fournir libutil.dylib.
Une autre source d'information pour le portage est le Wiki MetaPkg Wiki.
Vous pouvez aussi lire la note technique d'Apple TN2071 : "Porting Command Line Unix Tools to Mac OS X" sur le portage d'outils Unix en ligne de commande sous Mac OS X.
Une caractéristique de Mach-O, qui surprend beaucoup de gens, est la distinction stricte entre les librairies partagées et les modules chargeables dynamiquement. Sur les systèmes ELF, cette distinction n'existe pas ; n'importe quelle partie de code partagé peut être utilisée comme librairie ou chargée dynamiquement. Utilisez otool -hv un_certain_fichier pour connaître le type de fichier de un_certain_fichier.
Les librairies partagées de Mach-O ont un type de fichier MH_DYLIB et une extension .dylib. Elles peuvent être liées avec les options statiques habituelles de l'éditeur de liens, par exemple -lfoo pour libfoo.dylib. Toutefois, elles ne peuvent pas être chargées en tant que modules. (Note subsidiaire : les librairies partagées peuvent être chargées dynamiquement par le biais d'une API. Néanmoins, cette API est différente de l'API pour les lots et sa sémantique la rend inutilisable pour une émulation dlopen(). En particulier, les librairies partagées ne peuvent être déchargées).
Les modules chargeables sont appelés "lots" dans le jargon Mach-O. Ils ont un type de fichier MH_BUNDLE. Ils peuvent avoir n'importe quelle extension, car aucun des éléments concernés n'en tient compte. Apple recommande l'extension .bundle, mais la plupart des logiciels portés utilisent .so au nom de la compatibilité. Les lots peuvent être chargés dynamiquement et déchargés via les API dyld, et il existe une interface qui émule dlopen() au sommet de l'API. Il est impossible de lier des lots comme s'ils étaient des librairies partagées. Toutefois, il est possible de lier un lot avec des librairies partagées réelles ; celles-ci sont automatiquement chargées lorsque le lot est chargé.
Sur un système ELF, les numéros de versions sont, en général, ajoutés au nom de la librairie partagée, après l'extension, par exemple : libqt.so.2.3.0. Sur Darwin, les numéros de version sont placés entre le nom de la librairie et l'extension, par exemple : libqt.2.3.0.dylib. Notez que cela vous permet de demander une version spécifique de librairie à l'édition de liens, en utilisant -lqt.2.3.0 dans l'exemple ci-dessus.
Lorsque vous créez une librairie partagée, vous pouvez indiquer un nom à utiliser lors de la recherche de la librairie à l'exécution. C'est une pratique usuelle et cela permet d'installer plusieurs versions majeures d'une librairie en même temps. C'est ce qu'on appelle le soname sur les systèmes ELF. Sur Darwin, la différence est que vous pouvez (et devez) indiquer le chemin complet en même temps que le nom du fichier. Ceci élimine la nécessité des options "rpath" et du système de cache ldconfig/ld.so.cache. Pour utiliser une librairie qui n'est pas encore installée, vous pouvez définir la valeur de la variable d'environnement DYLD_LIBRARY_PATH ; voir la man page dyld pour de plus amples informations.
Le format Mach-O permet aussi un vrai contrôle du numéro de version mineure, inconnu sur les systèmes ELF. Chaque librairie Mach-O portent deux numéros de versions : une version "courante" et une version "compatible". Les deux numéros de versions sont constitués de trois chiffres séparés par des points, par exemple 1.4.2. Le premier chiffre ne peut être nul. Les second et troisième peuvent être omis, ils ont alors la valeur zéro. Quand aucune version n'est spécifiée, le numéro par défaut est 0.0.0, ce qui est une sorte de valeur passe-partout.
La version "courante" n'est donnée qu'à titre d'information. La version "compatible" sert au contrôle décrit ci-après. Quand un exécutable est lié, le numéro de version de la librairie est copié dans l'exécutable. Lorsque l'exécutable est lancé, le numéro de version copié dans l'exécutable est comparé à celui de la librairie utilisée. dyld génère une erreur d'exécution et arrête l'exécution du programme, sauf si le numéro de version de la librairie utilisée est égal ou supérieur à celui utilisé durant l'édition de liens.
Par défaut, Darwin génère du code indépendant de la position (PIC). En fait, le code PowerPC est indépendant de la position par construction, si bien qu'il n'y a ni perte de place, ni dégradation de performance. Vous n'avez donc pas besoin de spécifier l'option PIC lors de la compilation d'une librairie partagée ou d'un module. Toutefois, l'éditeur de liens n'admet pas les symboles "common" dans les librairies partagées, si bien que vous devez utiliser l'option de compilation -fno-common.
Pour construire une librairie partagée, vous invoquez le compilateur avec l'option -dynamiclib. Voici un exemple qui permettra de mieux comprendre le processus. Nous allons construire une librairie appelée libfoo, composée des fichiers sources source.c et code.c. Le numéro de version est 2.4.5, où 2 est le numéro de révision majeure (changement d'API incompatible), 4 est le numéro de révision mineure (compatible avec un retour à une API antérieure) et 5 est le compteur de révision des bogues (on l'appelle parfois une "mini-révision", elle indique des changements totalement compatibles avec l'API). La librairie ne dépend d'aucune autre librairie partagée et sera installée dans /usr/local/lib.
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
Observez quelles sont les parties du numéro de version qui sont utilisées et où elles le sont. Lors de l'édition de lien avec cette librairie, on utilise normalement le drapeau -lfoo, qui donne accès au lien symbolique libfoo.dylib. Quel que soit le lien symbolique ou le fichier utilisé, c'est le nom_d'installation qui est écrit dans le programme. Cela signifie que l'on peut supprimer le lien symbolique "de plus haut niveau" (celui qui est le moins spécifique d'une version donnée) libfoo.dylib après compilation. Lors d'une mise à jour mineure, on change juste la cible du lien symbolique libfoo.2.dylib utilisé par l'éditeur de lien dynamique.
Pour construire un module chargeable, vous invoquez le compilateur avec l'option -bundle. Si le module utilise des symboles provenant du programme hôte, vous aurez à spécifier -undefined suppress pour autoriser des symboles non définis, ainsi que -flat_namespace, indispensable avec le nouvel éditeur de liens de Mac OS X 10.1. Petit exemple explicatif :
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
Remarquez qu'aucun numéro de version n'est utilisé. Il est possible, en théorie, d'en utiliser un, mais, en pratique, cela ne présente aucun intérêt. Notez aussi qu'il n'y a pas de restriction de nom pour les lots. Quelques paquets placent un "lib" avant le nom, parce que certains systèmes l'exigent ; cela ne présente aucun risque, car le programme utilise le nom de fichier complet lors du chargement du module.
Les paquets GNU qui construisent des librairies utilisent GNU libtool pour masquer les procédures de construction et d'installation de librairie dépendantes des plate-formes.
Grosso modo, on trouve quatre variantes de libtool :
libtool 1.3 : la plus courante. La dernière version de cette branche est la 1.3.5. Elle ignore Darwin et ne construit que des librairies statiques. On la reconnaît à la présence des fichiers ltconfig et ltmain.sh dans l'arborescence du source.
libtool 1.4 : longtemps en chantier et récemment publiée en tant que nouvelle version stable, cette branche intègre mieux autoconf. Malheureusement, cela rend difficile la migration des paquets qui utilisent la version 1.3. Elle gère Darwin 1.3 / Mac OS X 10.0 sans problème et nécessite une petite rustine pour fonctionner avec Mac OS X 10.1. Elle se distingue par l'absence de ltconfig. Les versions 1.3b et 1.3d sont des versions de développement de la branche 1.4 et doivent être utilisées avec prudence.
Les branches multilangages : aussi appelée MLB, cette version de libtool était dans une branche de développement parallèle et gérait C++ et Java (via gcj). Elle est maintenant intégrée dans la branche de développement principale. Les versions récentes gèrent Darwin 1.3 et Mac OS X 10.0 sans modification. La MLB se reconnaît à la présence des fichiers ltcf-c.sh, ltcf-cxx.sh et ltcf-gcj.sh.
La branche de développement actuelle : c'est la version de développement qui sera un jour publiée en tant que libtool 1.5. Elle résulte de la fusion de la version 1.4 et de la MLB. Elle gère C, C++ et Java (via gcj). Malheureusement, il est difficile de la distinguer de la version 1.4, vous devez tester le numéro de version dans ltmain.sh.
En conclusion, libtool 1.3.x et les paquets qui l'utilisent (c'est le cas de la majorité des paquets utilisant libtool) nécessitent une rustine pour construire des librairies partagées sur Darwin. Apple inclut une version modifiée de libtool 1.3.5 dans Mac OS X, mais, dans la plupart des cas, elle ne fonctionne pas correctement. Christoph Pfisterer a amélioré cette version modifiée pour coder en dur le chemin correct et utiliser le numéro de version complet. Les changements ont été incorporés en amont dans les versions définitives et les versions de développement à partir de la version 1.4. Les membres de l'équipe Fink continuent à réaliser des améliorations et à les faire parvenir aux mainteneurs de libtool. Le modèle de numérotation des versions est compatible pour toutes les versions de libtool.
Note subsidiaire : la librairie libltdl, incluse dans toutes les versions de libtool, ne fonctionne sur Darwin que si dlcompat est installé. Elle est incluse dans Mac OS X à partir de la version 10.3. Pour les versions antérieures, on peut installer la famille de paquets "dlcompat"
Si vous construisez vous-même la version 1.3.5, vous devrez appliquer cette rustine [mise à jour du 09/06/2002] au source de libtool 1.3.5, puis supprimer les fichiers ltconfig et ltmain.sh. (Ils seront recréés à partir des fichiers .in adéquats lorsque vous lancerez configure et make). Ceci est fait automatiquement, d'ailleurs, dans le paquet actuel libtool 1.3.5 de Fink.
Mais ce n'est que la moitié du travail - chaque paquet utilisant libtool contient ses propres copies de ltconfig et ltmain.sh. Si bien que vous devez les remplacer dans chaque paquet que vous voulez construire en tant que librairie partagée. Notez que vous devez le faire avant de lancer le script configure. Vous pouvez récupérer les deux fichiers ici : ltconfig (98 ko) et ltmain.sh (110 ko) [tous deux mis à jour au 09/06/2002].
Il y a au moins trois versions différentes de libtool 1.4.x en usage à l'heure actuelle (1.4.1, 1.4.2, ainsi que des versions de développement plus récentes). Elles posent toutes problème avec Darwin, cependant les modifications à effectuer diffèrent selon la version. Le paquet "libtool 1.4" fourni via Fink possèdent déjà toutes les rustines nécessaires. Cependant, il vous faudra encore modifier vous-même les fichiers ltmain.sh et configure des paquets concernés pour qu'ils fonctionnent correctement.
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
Ce problème est résolu dans certaines versions de libtool postérieures à la 1.4.2.
--- 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,
et la rustine pour résoudre ce problème est le sujet de ces messages :
http://mail.gnu.org/archive/html/libtool/2002-04/msg00043.html.
Pour plus d'informations sur libtool lui-même et ce qu'il fait, consultez la page de libtool.
Note subsidiaire : les Developer Tools d'Apple contiennent un programme appelé, lui aussi, libtool, qui est utilisé par le compilateur pour construire des librairies partagées. Cependant, cet outil n'a rien à voir avec GNU libtool. L'outil GNU libtool qu'Apple fournit est installé sous le nom de glibtool. Ceci peut être réalisé en configurant GNU libtool avec --program-transform-name=s/libtool/glibtool/.
Fink a fait la transition de OS X 10.0 à OS X 10.1 facilement, et cela, en partie, grâce à la planification des changements à faire. Nous essayerons de faire de même pour la prochaine transition, mais peu de détails nous sont connus pour l'instant.
Nous savons que OS X 10.2 utilisera bash au lieu de zsh dans le but de fournir la fonctionnalité /bin/sh. Ceci a au moins trois conséquences pour Fink.
CompileScript: echo "nothing to do"
../libtool: test: too many argumentsQuand cela arrive, configure contient ce qui suit :
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)'Voici une rustine (mais elle doit être appliquée avec précaution, car quelquefois il y a aussi d'autres problèmes avec libtool, si bien que cette rustine doit être appliquée à la main) :
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 utilise le compilateur gcc3.
Certains paquets qui ont des modules chargeables et qui utilisent libtool échouent avec une erreur install_name, car libtool passe le drapeau -install_name même avec le drapeau -bundle (alors que cela n'est pas strictement nécessaire). Ce comportement était accepté par le compilateur gcc2 mais n'est plus accepté maintenant par le compilateur gcc3. Vous trouverez la rustine ici. Notez que vous n'avez pas besoin de cette rustine si votre paquet utilise libtool-1.3.5 (par exemple, si vous utilisez UpdateLibtool: True) puisque elle a déjà été insérée dans une version révisée du fichier ltconfig (accessible dans des préversions de fink).
Un autre problème avec le compilateur gcc3 est l'incompatibilité pour les ABI C++ entre gcc2 et gcc3. En pratique, ceci signifie que les programmes C++ compilés avec gcc3 ne peuvent être liés à des librairies compilées avec gcc2.
Sous Mac OS X 10.2, /usr/bin/perl correspondait à la version 5.6.0 de perl et l'architecture était représentée par la chaîne de caractères "darwin". Sous Mac OS X 10.3, /usr/bin/perl correspond à la version 5.8.1 de perl, et l'architecture est représentée par la chaîne de caractères "darwin-thread-multi-2level". Ces changements n'affectent probablement pas l'utilisation courante de l'exécutable perl lors de la création de paquets, car chaque exécutable perl sait où trouver ses propres modules. Les mainteneurs de paquets de module perl ("-pm") qui suivent les règles d'empaquetage des modules perl en vigueur et celles des scripts CompileScript et InstallScript n'ont pas de souci à se faire.
À partir de Mac OS X 10.3, il existe une définition complète du type socklen_t type. Pour l'utiliser, il faut ajouter au programme :
#include <sys/types.h> #include <sys/socket.h>
Mac OS X 10.3 comprend plusieurs librairies qui n'existaient pas dans les versions précédentes du système, et étaient donc fournies en tant que paquets Fink. Il s'agit de :
| Librairies | Notes |
|---|---|
| libpoll |
Les fichiers /usr/lib/libpoll.dylib et /usr/include/poll.h sont toujours inclus, toutefois l'implémentation de cette librairie sous Mac OS X n'est pas complète. Si elle correspond à vos besoins, vous pouvez supprimer les dépendances des paquets Fink "libpoll" et "libpoll-shlibs". Le code de la librairie est incorporé dans libSystem ; cette librairie est toujours liée automatiquement. Cela signifie que le drapeau -lpoll n'est pas nécessaire si vous désirez utiliser l'implémentation Mac OS X. Sachez que Mac OS X fournit un fichier libpoll.dylib ; il se peut donc que -lpoll donne un résultat différent selon que le paquet Fink "libpoll" est installé ou non. |
| libdl |
Les fichiers /usr/lib/libdl.dylib et /usr/include/dlfcn.h sont inclus maintenant ; il n'y a donc plus besoin de dépendre des paquets Fink "dlcompat", "dlcompat-dev" et "dlcompat-shlibs". Le code de la librairie est incorporé dans libSystem ; cette librairie est toujours liée automatiquement. Cela signifie que le drapeau -ldl n'est plus nécessaire (mais son utilisation n'a aucun effet). |
| GNU getopt |
Cette librairie, qui comprend la fonction getopt_long(), a été incorporée dans libSystem et /usr/include/getopt.h ; vous n'avez donc pas besoin d'utiliser les paquets Fink "libgnugetopt" et "libgnugetopt-shlibs". Comme libSystem est automatiquement liée et que le répertoire /usr/include fait partie des répertoires automatiques de recherche des headers, vous pouvez supprimer tous les drapeaux -lgnugetopt et -I/opt/sw/include/gnugetopt qui avaient été ajoutés pour permettre d'accéder au paquet Fink "libgnugetopt". |
Lors de la migration d'un paquet vers Mac OS X 10.3, essayez de supprimer ces dépendances obsolètes, car il se peut que ces paquets soient supprimés des arborescences futures. Cela signifie qu'il faut un fichier de description différent pour chaque arborescence. Comme toujours, le champ Revision doit être incrémenté lors de changements faits sur un paquet. De cette façon, les utilisateurs qui passent de Mac OS X 10.2 à Mac OS X 10.3 voient les paquets spécifiques à la branche 10.3 comme "plus récents" que les paquets de l'arborescence 10.2. Par convention, le champ Revision doit être incrémenté de 10 unités lors d'une migration vers un arbre plus récent de façon à laisser une marge pour pouvoir mettre à jour les paquets des branches moins récentes.
Lors du test d'un paquet en migration, n'oubliez pas de désinstaller les paquets que vous avez supprimé du champ BuildDepends, pour éviter que le compilateur lie avec les librairies Fink installées.
/usr/bin/perl correspond maintenant à perl 5.8.6 ; la couche architecturale est toujours "darwin-thread-multi-2level".
Dans Mac OS X 10.4, de nombreux symboles ont changé de types. Si vous aviez précédemment défini un type explicitement, comme, par exemple, socklen_t en tant que int, cette définition risque de ne plus être correcte.
La fonction poll() dans Mac OS X 10.3 n'était qu'une émulation reposant sur select(). Sous Mac OS X 10.4, poll() est une vraie fonction implantée dans le noyau, mais elle est boguée lorsqu'elle est utilisée avec des sockets. Il vaut mieux l'ignorer complètement. On a appliqué sur le paquet glib2 de Fink une rustine qui permet d'utiliser une émulation complètement fonctionnelle. Vous ne courez donc aucun risque à utiliser l'implantation de fonctions similaires à poll de cette librairie.
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.fr.xml,v 1.16 2023/08/04 5:08:13 nieder Exp $