Portage - 3. GNU libtool

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.

3.1 État des lieux

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"

3.2 Rustine 1.3.5

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].

3.3 Adaptation de la version 1.4.x

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.

Le bogue du flat_namespace : ce problème ne survient que si vous utilisez libtool sur Mac OS X10.1 ou une version plus récente. Dans ce cas, libtool tente d'utiliser l'option -undefined suppress pour autoriser les symboles non définis, mais ne spécifie pas, en même temps, l'option -flat_namespace. À partir de la version 10.1, cela ne fonctionne plus. La rustine à appliquer est de la forme :

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.

Le bogue du module chargeable : ce bogue est provoqué par le comportement non-standard de zsh (qui est le shell par défaut dans les versions 10.0 et 10.1 ; à partir de la version 10.2, il est remplacé par bash). Le comportement non standard de zsh en matière d'utilisation des guillemets empêche de construire correctement des modules chargeables ; ce sont des librairies qui sont construites à la place (et, à la différence de ce qui se passe sur Linux, ce sont des choses réellement différentes sur Darwin). La rustine à appliquer pour résoudre ce problème ( tronquée, donc inutilisable sans modification) est de la forme :

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.

Le bogue d'accès aux librairies utilitaires : dans certains cas, libtool n'arrive pas à faire l'édition de liens avec les librairies utilitaires. Il génère alors des messages d'erreur "multiple definitions". Il semble que ceci soit causé par un problème plus fondamental dans libtool. Pour l'instant vous pouvez utiliser ce palliatif (qui supprime les symptômes mais non le problème, bien qu'il soit efficace). Merci à 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

Le bogue DESTDIR : certains paquets, qui définissent DESTDIR et utilisent libtool 1.4.2, ont des problèmes de réédition de liens. On trouvera une discussion sur ces problèmes dans les messages ci-dessous :
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.

3.4 Notes supplémentaires

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/.

Suite: 4. Préparation pour la version 10.2