Version imprimable Portage - 4. Préparation pour la version 10.2
4.1 Shell bash
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.
- Dans le passé, certains paquets de Fink créaient un CompileScript (ou un PatchScript, ou un InstallScript) qui ne faisait rien, simplement en mettant un point virgule dans le script. Ceci ne fonctionne pas avec bash et doit être remplacé par :
CompileScript: echo "nothing to do"
- Dans le passé, certains paquets de Fink utilisaient la construction
lib(foo|bar).dylibpour faire référence à deux librairies simultanément ; ceci ne fonctionne pas avec bash (et l'alternativelib{foo,bar}.dylibne fonctionne pas avec zsh). La solution : écrire les noms intégralement. - Avec bash, une rustine de libtool est nécessaire dans de nombreux cas, pour éviter que les librairies ne soient construites sans numéro de version. Note : vous n'avez pas besoin de cette rustine avec libtool-1.3.5, par exemple, si vous utilisez UpdateLibtool: True . Le symptôme : quand vous construisez sous bash, vous voyez :
../libtool: test: too many arguments
Quand cela arrive,configurecontient 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='~'
4.2 Compilateur gcc3
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.