La première chose importante à savoir est comment reconstruire proprement le support pour les autotools, étant donnée 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.

Beaucoup de paquets fournissent 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 (comme ils peuvent se contenter d'appeler les outils les uns après les autres sans pour autant leur passer en argument de 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 patché un paquet. C'est pour cette raison que autoreconf n'est pas recommandé et é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 patcher les fichiers 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 dans l'eclass autotools ont aussi l'avantage de ne pas présenter aux utilisateurs de nombreux messages non formatés (dans le cas d'avertissements) ou rien (dans le cas où il n'y a pas de problème) ; au lieu de cela, elle fournissent des messages sur leur status avec ebegin et eend pour que les utilisateurs sachent ce qu'il se passe, elles tracent aussi les cas d'erreurs en fournissant des messages de sortie à la epatch dans le cas d'erreurs. 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 aux paquets nécessaires (sys-devel/autoconf, sys-devel/automake, sys-devel/libtool).

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 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, ceci signifie que le paquet fournissant 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 aux 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 écrits 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 utilisant 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
...  

Ceci est souvent évité par les développeurs de logiciels qui passent simplement le paramètre -I m4 à aclocal lorsqu'ils font leur paquet. Comme ajouter un patch pour résoudre ce problème est trop violent, 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ù est le configure ; pour résoudre ce genre de problème, définissez le à la place à ${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 le fichier avec la macro indéfinie 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 patch 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, ainsi il est souvent mieux d'en informer les développeurs du logiciel dès que possible pour que les prochaines versions ne nécessitent pas de tels "hacks".

Une autre erreur commune, cette fois avec automake est un échec à cause de fichiers manquants, tels que NEWS ou README. Ceci est à cause du fait que les autotools supposent, si personne ne leur précise le contraire, qu'ils travaillent sur un paquet GNU, qui ont une série de fichiers dû au guide du style de code de GNU, et échoue 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 si tous les fichiers requis par GNU sont 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 (en l'envoyant 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 des fichiers requis par le configure.in ou configure.ac au lieu du Makefile.am, et sont souvent les fichiers config.guess et config.sub, le problème est que le paquet n'est pas proprement "bootstrappé". Pour résoudre ceci, 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.

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 considérées comme entrée pour 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é 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