Comment corriger les échecs des autotools

1.  Introduction

Par le terme autotools, on se réfère usuellement aux outils développés par le projet GNU pour créer des systèmes de compilation indépendants de la plate-forme et du système : autoconf, automake et libtool. Même si chaque paquet ne les utilise pas tous en même temps, c'est le cas pour la plupart des modernes. Souvent, de plus vieux paquets n'utilisent pas automake et libtool ; les paquets KDE utilisent un système de compilation plus complexe qui dépend au final des trois logiciels cités plus haut.

On reconnaît facilement un paquet dont le système de compilation est basé sur les autotools : s'il y a un script configure et un fichier configure.in ou configure.ac, le système de compilation est basé sur autoconf. S'il y a un ou plusieurs fichiers Makefile.am dans divers sous-répertoires, il est aussi basé sur automake. S'il y a un script ltmain.sh, il utilise aussi libtool.

Pour compiler un paquet basé sur les autotools, les outils eux-mêmes ne sont pas strictement nécessaires : le script configure est un simple script Bourne Shell (usuellement, mais nous en reparlerons plus tard) et il transforme les fichiers Makefile.in en un Makefile, plus simple, pour make (ou, plus souvent, gmake). Certains problèmes tels que les échecs de compilation avec --as-needed ou les automagic dependencies nous forcent à relancer ces outils pour prendre en compte des correctifs lors de la création des scripts et schémas des Makefiles.

Ce guide ne donnera pas de consigne qui explique corriger les erreurs des paquets en utilisant les autotools car c'est un trop vaste sujet qui requiert d'expliquer beaucoup de choses. Pour une simple introduction aux erreurs les plus courantes faites en utilisant les autotools, il est plutôt suggéré de lire l'article best practices with autotools. Ce guide décrit plutôt les cas courants où relancer les autotools amène à des erreurs, soit à la reconstruction du script, soit à la compilation.

2.  Relancer les autotools

La première chose importante à savoir est comment reconstruire proprement le support pour les autotools, étant donné que c'est un problème courant qui cause des erreurs dans certains ebuilds. L'ordre dans lequel les autotools sont appelés est important comme l'un dépend de l'autre et que le résultat final dépend beaucoup du respect de cet ordre.

De nombreux paquets ne fournissent qu'un seul script, souvent appelé autogen.sh ou bootstrap.sh, qui sert à exécuter ces outils dans l'ordre qu'ils pensent être le bon, souvent en définissant des variables pour que la bonne version des outils soit appelée (différentes versions des autotools sont souvent incompatibles). Ces scripts sont, en général, préférés aux autres méthodes mais contiennent souvent des erreurs ou supposent être sur un certain environnement qui peut être propre à une autre distribution. Pour cette raison, ils doivent être attentivement vérifiés et, lorsqu'ils n'apportent aucun avantage par rapport aux autres méthodes (ils pourraient se contenter d'appeler les outils les uns après les autres sans pour autant leur passer en argument des paramètres spéciaux ou vérifier leur valeur de retour), ils ne devraient pas être utilisés.

Le paquet autoconf fournit un script automatique, appelé autoreconf, qui devrait détecter automatiquement quels autotools sont utilisés et les appeler, mais il échoue trop souvent à détecter la bonne version ou plante à cause de cas imprévus. De plus, il appelle autopoint, le script qui rajoute le support pour gettext à un paquet. Cet appel n'est presque jamais requis après avoir corrigé un paquet. C'est pour cette raison qu'autoreconf n'est pas recommandé et est évité autant que possible (la même chose prévaut pour certains scripts maison fournis par des paquets qui les utilisent).

Pour pallier à ces problèmes, l'eclass autotools a été ajoutée. Cette eclass fournit des fonctions autour des autotools GNU : eautoconf, eautomake, _elibtoolize (avec le préfixe _ pour éviter les collisions avec les fonctions elibtoolize de l'eclass libtool) et la plus importante eautoreconf. Cette fonction n'utilise pas le script cassé autoreconf, mais analyse plutôt les fichiers présents pour le support des autotools et les lance dans le bon ordre. Il appelle aussi la fonction elibtoolize pour appliquer les correctifs pour le support de libtool si nécessaire, évitant ainsi les problèmes lorsqu'elle est appelée avant la recréation des fichiers des autotools.

Les fonctions de l'eclass autotools ont aussi l'avantage de remplacer le surplus (en cas de problème) ou l'absence (en cas de succès) de messages par des ebegin/eend afin que les utilisateurs sachent ce qu'il se passe. Elles tracent aussi les erreurs en fournissant des messages à la epatch en cas d'échec. Pour cette raison, ces fonctions sont préférées aux appels manuels ou mauvais ou aux scripts presque inutiles fournis dans les paquets. Un autre avantage est que l'eclass autotools rajoute aussi les dépendances à la compilation des paquets nécessaires (sys-devel/autoconf, sys-devel/automake, sys-devel/libtool).

Macros potentiellement non définies

L'erreur la plus commune avec les autotools est à propos du message d'autoconf : « possibly undefined macro: UNE_MACRO ». Ce message est affiché quand une macro est appelée depuis le fichier configure.ac ou configure.in mais qu'elle n'est pas définie dans le fichier aclocal.m4 créé par aclocal.

Ceci arrive souvent car la macro mentionnée n'est pas disponible lorsque aclocal est appelé. Comme, par défaut, il charge les macros trouvées dans /usr/share/aclocal, cela signifie que le paquet qui fournit cette macro n'est pas installé (ou la macro est appelée avec un mauvais nom). Comme le second cas est soit trivial soit complexe à résoudre, nous nous intéresserons au premier, une définition de macro manquante.

Les macros écrites par les développeurs pour que leur programme soit détecté dans le système en utilisant les autotools sont souvent écrites dans des fichiers m4 qui sont installés dans le susmentionné répertoire /usr/share/aclocal. Comme beaucoup de paquets utilisent ces macros pour des dépendances optionnelles, un fichier m4 peut être nécessaire mais ne pas être installé sur le système où les autotools sont appelés. Pour pallier à ce problème il est possible de copier le fichier m4 dans un sous-répertoire fourni avec le paquet lui-même.

Malheureusement, pour utiliser ce sous-répertoire, souvent nommé m4, il est nécessaire d'en informer aclocal. Dans les projets qui utilisent automake, il est possible de définir ceci dans le fichier Makefile.am principal en définissant la variable ACLOCAL_AMFLAGS :

...
ACLOCAL_AMFLAGS = -I m4
...

Cet ajout est souvent évité par les développeurs de logiciels qui passent simplement le paramètre -I m4 à aclocal lorsqu'ils font leur paquet. Pour ne pas devoir faire un correctif juste pour résoudre ce problème, il est plus simple, si le paquet a un répertoire avec les fichiers m4 requis, de le définir dans la variable AT_M4DIR. La même chose vaut si le paquet n'utilise pas automake mais seulement autoconf.

src_unpack() {
        ...
        AT_M4DIR="m4" eautoreconf
}

Dans de rares cas, le programme utilise un système de construction à la Cygnus avec des « sous-configure ». L'exemple précédent peut échouer puisqu'il essaie de trouver un sous-répertoire m4 là où se trouve le configure. Pour résoudre ce genre de problème, définissez-le plutôt à ${S}/m4.

Moins souvent, mais ça arrive tout de même, il n'y a pas de sous-répertoire avec des fichiers m4 ou bien le fichier avec la macro manquante n'est pas présent. Pour résoudre ce problème, vous devez trouver quel paquet fournit le fichier m4 et ensuite l'ajouter à ce répertoire, soit avec un correctif, soit en le mettant sur les miroirs et ensuite en l'ajoutant au SRC_URI (auquel cas vous devez ajouter ${WORKDIR} à la liste des répertoires dans lesquels chercher ou le déplacer dans le bon répertoire). Ce genre de problème est un des plus pénibles. Le mieux reste souvent d'en informer les développeurs du logiciel dès que possible pour que les prochaines versions ne nécessitent pas de telles bidouilles.

Conflit de version d'automake au lancement d'eautoreconf

Parfois lors du lancement d'eautoreconf, celui-ci échoue en signalant une erreur de conflit de version. Vous vous seriez attendu à ne jamais voir cela, puisque la fonction eautomake s'occupera de relancer tous les autotools si la version d'automake utilisée pour compiler le paquet diffère de celle utilisée par l'ebuild ; de plus, pendant l'eautoreconf, les outils sont lancés de façon à écraser de force les fichiers, afin de faire disparaître les références à l'automake utilisé à l'origine.

La seule (ou plutôt au moins une) cause de ceci est une mauvaise connaissance des autotools par le développeur de l'ebuild. Quand il est confronté au problème décrit plus haut des macros potentiellement non définies, il peut se sentir contraint de simplement copier le fichier aclocal.m4 précédent de l'archive tar originale sous un autre nom, pour en préserver les définitions de macro. Malheureusement ceci écrase les macros d'automake, causant cette échec presque incompréhensible.

Automake échoue, requiert des fichiers manquants

Une autre erreur commune, cette fois avec automake, est un échec causé par l'absence de fichiers tels que NEWS ou README. En effet, les autotools supposent, si personne ne leur précise le contraire, qu'ils travaillent sur un paquet GNU, dont le style de code impose la présence une série de fichiers, et échouent ainsi quand ces fichiers manquent. Dans ces cas, automake doit être appelé avec le paramètre --foreign, qui lui dit de ne pas échouer si les fichiers requis par GNU ne sont pas présents.

Encore une fois, la fonction eautomake tente de rendre plus simple la reconstruction des autotools en vérifiant que tous les fichiers requis par GNU soient présents et en appelant ensuite automake avec la bonne option si ce n'est pas le cas. La bonne façon de résoudre ce problème (à envoyer aux développeurs du logiciel) est d'ajouter à la variable AUTOMAKE_OPTIONS l'option foreign pour qu'il sache tout seul qu'il doit utiliser le support « foreign ».

Quand les fichiers sont requis par le configure.in ou configure.ac au lieu du Makefile.am, ce sont souvent les fichiers config.guess et config.sub, le problème est que le bootstrap du paquet n'est pas correct. Pour le résoudre, automake doit être appelé avec les options --add-missing --copy. C'est ce que la fonction eautomake fait déjà, ainsi si vous rencontrez ce problème vous devriez penser à utiliser les fonctions fournies par l'eclass autotools au lieu d'appeler les outils manuellement ou avec d'éventuels scripts fournis dans le paquet.

Version des dépendances manquantes

Depuis l'été 2006, l'eclass autotools ne dépend plus de toutes les versions des paquets automake et autoconf automatiquement, ce qui signifie que vous ne pouvez pas supposer que les utilisateurs ont installé toutes les versions et les dépendances doivent être corrigées pour avoir les bonnes versions installées. Pour simplifier la gestion des dépendances et forcer les versions nécessaires, les variables WANT_AUTOCONF et WANT_AUTOMAKE sont prises en compte par l'eclass autotools qui se chargera de rajouter les bonnes dépendances.

 
WANT_AUTOCONF="2.1"
WANT_AUTOMAKE="1.4"

inherit autotools

Dans de nombreux cas, au lieu de dépendre d'une version spécifique d'automake ou autoconf, on veut dépendre de la dernière version disponible, probablement déjà présente sur le système des utilisateurs. Pour cette raison, l'eclass autotools accepte une valeur spéciale pour les variables mentionnées, latest, qui sera remplacée pour autoconf par 2.5 et pour automake soit 1.9 soit 1.10 selon ce qui est démasqué pour le système donné. Ceci est suggéré quand le paquet ne dépend pas de quelques options ou mauvais comportement de plus vieilles versions.

WANT_AUTOCONF="latest"
WANT_AUTOMAKE="latest"

inherit autotools

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.