Skip to content

Apprendre à compiler les choses à partir des sources (sur Unix/Linux/OSX)

Nos chercheurs vedettes ont épuisé leurs réserves de café, cherchant tout le temps la réponse, jusqu'à ce qu'Emilio trouve la réponse sur Beanstalk. Aujourd'hui, il la partage avec vous.

Solution :

Solution 1 :

Je m'excuse de répondre directement à tout, mais je ne connais aucun tutoriel utile, aucune FAQ, etc. Fondamentalement, ce qui suit est 8 ans de fabrication d'applications de bureau (que j'aide à distribuer), de frustration et de googling :

1. Comment puis-je déterminer les arguments à passer à ./configure ?

Pratique vraiment. Autotools est assez facile comme il est cohérent. Mais il y a beaucoup de choses là-bas qui utilisent cmake, ou des scripts de construction personnalisés. En général, vous ne devriez pas avoir à passer quoi que ce soit à configure, il devrait déterminer si votre système peut construire foo-tool ou non.

Configure et les outils GNU cherchent tous dans /, /usr et /usr/local pour les dépendances. Si vous installez quelque chose ailleurs (ce qui rend les choses douloureuses si la dépendance a été installée par MacPorts ou Fink), vous devrez passer un drapeau à configure ou modifier l'environnement du shell pour aider les outils GNU à trouver ces dépendances.

2. Comment les bibliothèques partagées fonctionnent sous OS X / Linux - où elles vivent sur le système de fichiers, comment ./configure && make les trouve, ce qui se passe réellement quand elles sont liées contre.

Sous Linux, elles doivent être installées dans un chemin que l'éditeur de liens dynamiques peut trouver, ce qui est défini par l'attribut LD_LIBRARY_PATH et le contenu de /etc/ld.conf. Sous Linux, c'est la même chose pour la plupart des logiciels open source presque toujours (sauf s'il s'agit d'un projet Xcode). Sauf que la variable d'environnement est DYLD_LIBRARY_PATH au lieu de .

Il y a un chemin par défaut que le linker recherche pour les bibliothèques. C'est /lib:/usr/lib:/usr/local/lib.

Vous pouvez compléter cela en utilisant la variable CPATH, ou CFLAGS ou n'importe quel autre nombre de variables d'environnement vraiment (commodément compliqué). Je suggère CFLAGS comme suit :

export CFLAGS="$CFLAGS -L/new/path"

Le paramètre -L ajoute au chemin du lien.

Les trucs modernes utilisent l'outil pkg-config. Les trucs modernes que vous installez installent aussi un fichier .pc qui décrit la bibliothèque et où elle se trouve et comment s'y lier. Cela peut rendre la vie plus facile. Mais il n'est pas fourni avec OS X 10.5 et vous devrez donc l'installer aussi. De plus, beaucoup de deps de base ne le supportent pas.

L'acte de liaison est juste "résoudre cette fonction à l'exécution", en réalité c'est une grande table de chaînes.

3. Quelles sont les différences réelles entre une bibliothèque partagée et une bibliothèque liée statiquement ? Pourquoi ne puis-je pas tout lier statiquement (la RAM et l'espace disque sont bon marché de nos jours) et donc éviter les conflits de version de bibliothèque bizarres ?

Lorsque vous liez à un fichier de bibliothèque statique, le code devient une partie de votre application. Ce serait comme s'il y avait un fichier .c géant pour cette bibliothèque et que vous le compiliez dans votre application.

Les bibliothèques dynamiques ont le même code, mais lorsque l'application est exécutée, le code est chargé dans l'application au moment de l'exécution (explication simplifiée).

Vous pouvez lier statiquement à tout, cependant, malheureusement presque aucun système de construction ne rend cela facile. Vous devrez modifier manuellement les fichiers du système de compilation (par exemple Makefile.am, ou CMakeLists.txt). Cependant, cela vaut probablement la peine d'apprendre si vous installez régulièrement des choses qui nécessitent différentes versions de bibliothèques et que vous trouvez difficile d'installer les dépendances en parallèle.

L'astuce consiste à changer la ligne de liaison de -lfoo à -l/path/to/static/foo.a.

Vous pouvez probablement trouver et remplacer. Ensuite, vérifiez que l'outil ne lie pas le .so ou la dylib en utilisant ldd foo ou otool -L foo.

Un autre problème est que toutes les bibliothèques ne compilent pas en bibliothèques statiques. Beaucoup le font. Mais alors MacPorts ou Debian peut avoir décidé de ne pas l'expédier.

4. Comment puis-je savoir quelles bibliothèques j'ai installées, et quelles versions ?

Si vous avez des fichiers pkg-config pour ces bibliothèques, c'est facile :

pkg-config --list-all

Sinon, vous ne pouvez souvent pas facilement. La dylib peut avoir un soname (ie. foo.0.1.dylib, le soname est 0.1) qui est le même que la version de la bibliothèque. Cependant, ce n'est pas obligatoire. Le soname est une caractéristique de calcul binaire, vous devez changer la majeure partie du soname si vous changez le format des fonctions de la bibliothèque. Vous pouvez donc obtenir un soname de version 14.0.5 pour une bibliothèque 2.0. Bien que cela ne soit pas courant.

J'ai été frustré par ce genre de chose et j'ai développé une solution pour cela sur Mac, et j'en parle ensuite.

5. Comment puis-je installer plus d'une version d'une bibliothèque sans casser mon système normal ?

Ma solution à ce sujet est ici : http://github.com/mxcl/homebrew/

J'aime installer à partir de la source, et je voulais un outil qui le rendait facile, mais avec une certaine gestion des paquets. Donc, avec Homebrew, je construis, par exemple, wget moi-même à partir de la source, mais je m'assure d'installer vers un préfixe spécial :

/usr/local/Cellar/wget/1.1.4

J'utilise ensuite l'outil homebrew pour symlinker tout cela dans /usr/local, de sorte que j'ai toujours /usr/local/bin/wget et /usr/local/lib/libwget.dylib.

Plus tard, si j'ai besoin d'une version différente de wget, je peux l'installer en parallèle et juste changer la version qui est liée dans l'arbre /usr/local.

6. Si j'installe des trucs à partir des sources sur un système qui est autrement géré à l'aide de paquets, quelle est la façon la plus propre de le faire ?

Je crois que la façon Homebrew est la plus propre, alors utilisez-la ou faites l'équivalent. Installez dans /usr/local/pkgs/nom/version et symlink ou hard link le reste dedans.

Utilisez /usr/local. Chaque outil de construction qui existe y cherche les dépendances et les en-têtes. Votre vie sera beaucoup plus plus facile.

7. En supposant que je parvienne à compiler quelque chose de compliqué à partir des sources, comment puis-je ensuite l'empaqueter pour que d'autres personnes n'aient pas à sauter à travers les mêmes cerceaux ? En particulier sur OS X....

S'il n'a pas de dépendances, vous pouvez goudronner le répertoire de construction et le donner à quelqu'un d'autre qui peut alors faire "make install". Cependant, vous ne pouvez le faire de manière fiable que pour les mêmes versions exactes d'OS X. Sur Linux, cela fonctionnera probablement pour des Linux similaires (par exemple Ubuntu) avec la même version du noyau et la même version mineure de libc.

La raison pour laquelle il n'est pas facile de distribuer des binaires sur Unix est due à la compatibilité binaire. Les gens de GNU, et tous les autres changent souvent leurs interfaces binaires.

En gros, ne distribuez pas de binaires. Les choses se casseront probablement de manière très étrange.

Sur Mac, la meilleure option est de faire un paquet macports. Tout le monde utilise macports. Sur Linux, il y a tellement de systèmes de construction et de combinaisons différentes, je ne pense pas qu'il y ait de meilleur conseil que d'écrire un article de blog sur la façon dont vous avez réussi à construire x outil dans y configuration étrange.

Si vous faites une description de paquet (pour macports ou homebrew) alors n'importe qui peut installer ce paquet, et cela résout aussi les problèmes de dépendance. Cependant, ce n'est souvent pas facile, et il n'est pas non plus facile d'obtenir que votre recette macports soit incluse dans l'arbre principal de macports. Aussi macports ne supporte pas les types d'installation exotiques, ils offrent un seul choix pour tous les paquets.

L'un de mes futurs objectifs avec Homebrew est de permettre de cliquer sur un lien sur un site Web (par exemple, homebrew://blah et il téléchargera ce script Ruby, installera les deps pour ce paquet et construira ensuite l'application. Mais oui, pas encore fait, mais pas trop délicat vu le design que j'ai choisi.

8. Quels sont les outils de ligne de commande que je dois maîtriser pour devenir bon dans ce domaine ? Des trucs comme otool, pkg-config, etc.

otool n'est vraiment utile qu'après coup. Il vous indique vers quoi le binaire construit est lié. Lorsque vous déterminez les dépendances d'un outil que vous devez construire, il est inutile. Il en va de même pour pkg-config car vous aurez déjà installé la dépendance avant de pouvoir l'utiliser.

Ma chaîne d'outils est, lisez les fichiers README et INSTALL, et faites un configure --help. Regardez la sortie de la construction pour vérifier qu'elle est saine. Analysez toute erreur de compilation. Peut-être à l'avenir, demander sur serverfault 🙂

Solution 2 :

C'est un sujet énorme donc commençons par les bibliothèques partagées sur Linux (ELF sur Linux et Mach-O sur OS X), Ulrich Drepper a une bonne introduction à l'écriture de DSO (dynamic shared objects) qui couvre une partie de l'histoire des bibliothèques partagées sur Linux disponible ici, y compris pourquoi elles sont importantes...

Ulrich décrit également pourquoi la liaison statique est considérée comme nuisible l'un des points clés ici est les mises à jour de sécurité. Les dépassements de tampon dans une bibliothèque commune (par exemple zlib) qui est liée de manière extensive de manière statique peuvent causer un énorme surcharge pour les distributions - cela s'est produit avec zlib 1.1.3 (avis de Red Hat).

ELF

La page de manuel de l'éditeur de liens ld.so

man ld.so 

explique les chemins et fichiers de base impliqués dans la liaison dynamique d'exécution. Sur les systèmes Linux modernes, vous verrez des chemins supplémentaires ajoutés via /etc/ld.so.conf.d/ ajouté généralement via un include glob dans /etc/ld.so.conf.

Si vous voulez voir ce qui est disponible dynamiquement via votre configuration ld.so, vous pouvez exécuter

ldconfig -v -N -X

La lecture du howto DSO devrait vous donner un bon niveau de base de connaissances afin de pouvoir ensuite comprendre comment ces principes s'appliquent à Mach-O sur OS X.

Mach-O

Sur OS X le format binaire est Mach-O. La documentation du système local pour l'éditeur de liens est

man dyld

La documentation sur le format Mach est disponible auprès d'Apple

Outils de construction UNIX

Les outils communs configure, make, make install est généralement fourni par GNU autotools qui a un livre en ligne qui couvre une partie de l'histoire de la séparation configure/build et de la chaîne d'outils GNU. Autoconf utilise des tests pour déterminer la disponibilité des fonctionnalités sur le système de construction cible, il utilise le langage macro M4 pour cela. Automake est essentiellement une méthode de template pour les Makefiles, le template étant généralement appelé Makefile.am qui sort un Makefile.in que la sortie de autoconf (le script configure) convertit en Makefile.

Le programme GNU hello agit comme un bon exemple pour comprendre la chaîne d'outils GNU - et le manuel inclut la documentation autotools.


Solution 3 :

Simon ! Je sais ce que tu ressens ; j'ai lutté avec cette partie de l'apprentissage de Linux, aussi. Sur la base de mes propres expériences, j'ai écrit un tutoriel sur certains des éléments que tu abordes (principalement comme une référence pour moi-même !): http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html. Je pense que vous apprécierez ma note sur la simplicité de la construction et de l'installation des applications Python 🙂

J'espère que cela vous aidera ! Et bonne compilation.

Tim Jones


Construction/Installation d'une application à partir des sources dans Ubuntu Linux.

Bien que les dépôts Ubuntu soient remplis d'excellentes applications, à un moment ou à un autre, vous allez forcément tomber sur cet outil " indispensable " qui n'est pas dans les dépôts (ou qui n'a pas de paquet Debian) ou vous avez besoin d'une version plus récente que celle des dépôts. Que devez-vous faire ? Eh bien, vous devez construire l'application à partir des sources ! Ne vous inquiétez pas, ce n'est pas aussi compliqué que cela en a l'air. Voici quelques conseils, basés sur mon expérience d'amateur ! (Bien que j'utilise Ubuntu pour cet exemple, les concepts généraux devraient être applicables à la plupart des distributions Unix/Linux, comme Fedora, et même la plateforme Cygwin sous Windows).

Le processus de base pour construire (compiler) la plupart des applications à partir des sources suit cette séquence : configurer --> compiler --> installer. Les commandes typiques d'Unix/Linux pour faire ces choses sont : config --> make --> make install. Dans certains cas, vous trouverez même des pages web qui montrent que tous ces éléments peuvent être combinés en une seule commande :

$ config && make && make install

Bien sûr, cette commande suppose qu'il n'y a aucun problème dans aucune de ces étapes. C'est là que le plaisir entre en jeu !

Mise en route

Si vous n'avez jamais compilé une application à partir des sources sur votre système, vous aurez probablement besoin de la configurer avec quelques outils de développement généraux, tels que la commande gcc suite de compilateurs, certains fichiers d'en-tête communs (pensez à cela comme du code qui a déjà été écrit par quelqu'un d'autre et qui est utilisé par le programme que vous installez), et l'outil make. Heureusement, dans Ubuntu, il existe un métapaquet appelé build-essential qui va installer tout cela. Pour l'installer (ou simplement s'assurer que vous l'avez déjà !), exécutez cette commande dans le terminal :

$ sudo apt-get install build-essential

Maintenant que vous avez la configuration de base, téléchargez les fichiers sources de l'application et enregistrez-les dans un répertoire pour lequel vous avez les droits de lecture/écriture, comme votre répertoire "home". Typiquement, ils seront dans un fichier d'archive avec une extension de fichier soit .tar.gz ou .tar.bz2. Le site .tar signifie simplement qu'il s'agit d'une "archive sur bande", c'est-à-dire un regroupement de fichiers qui préserve leur structure de répertoire relative. Le site .gz signifie gzip (GNU zip), qui est un format de compression populaire sous Unix/Linux. De même, le symbole .bz2 représente bzip2, qui est un format de compression plus récent qui fournit une compression plus élevée (taille de fichier compressé plus petite) que gzip.

Après avoir téléchargé le fichier source, ouvrez une fenêtre de terminal (System Terminal dans le menu Ubuntu) et passez dans le répertoire où vous avez enregistré votre fichier. (Je vais utiliser ~/download dans cet exemple. Ici, '~' est un raccourci vers votre répertoire "personnel"). Utilisez la commande tar pour extraire les fichiers du fichier d'archive téléchargé :

Si votre fichier est une archive gzip (par exemple, il se termine par .tar.gz), utilisez la commande :

            $ tar -zxvf filename.tar.gz

Si votre fichier est une archive bzip2 (par exemple, se termine par .tar.bz2), utilisez la commande :

            $ tar -jxvf filename.tar.gz

Conseil : Si vous ne voulez pas avoir à vous
vous souvenir de tous les commutateurs
commande pour extraire des archives, je
recommande d'obtenir l'un (ou les deux) de
ces utilitaires : dtrx (mon préféré !)
ou deco (plus populaire). Avec l'un ou l'autre de ces
ces utilitaires, il vous suffit d'entrer le
nom de l'utilitaire (dtrx ou deco) et le nom du fichier.
le nom du fichier, il fait tout le reste.
le reste. Les deux "savent" comment
gérer la plupart des formats d'archives que
que vous êtes susceptible de rencontrer et ils
ont une excellente gestion des erreurs.

Lorsque vous construisez à partir des sources, il y a deux types d'erreurs communes que vous êtes susceptibles de rencontrer :

  1. Les erreurs de configuration se produisent lorsque vous exécutez le script de configuration (généralement nommé config ou configure) pour créer un makefile spécifique à votre configuration.
  2. Les erreurs de compilation se produisent lorsque vous exécutez la commande make (après que le makefile ait été généré) et que le compilateur est incapable de trouver un certain code dont il a besoin.

Nous allons examiner chacune d'entre elles et discuter de la façon de les résoudre.

Configuration et erreurs de configuration

Après avoir extrait le fichier d'archive du code source, dans le terminal, vous devez passer au répertoire qui contient les fichiers extraits. Typiquement, le nom de ce répertoire sera le même que le nom du fichier (sans la balise .tar.gz ou .tar.bz2 ). Cependant, il arrive que le nom du répertoire soit juste le nom de l'application, sans aucune information sur la version.

Dans le répertoire source, recherchez un README et/ou un fichier INSTALL (ou quelque chose avec des noms similaires). Ces fichiers contiennent généralement des informations utiles sur la façon de construire/compiler l'application et de l'installer, notamment des informations sur les dépendances. "Les dépendances" sont juste un nom fantaisiste pour d'autres composants ou bibliothèques qui sont nécessaires pour réussir la compilation.

Après avoir lu la section README et/ou INSTALL (et, si possible, consulté toute documentation en ligne pertinente pour l'application), recherchez un fichier exécutable (ayant la permission "x" définie sur le fichier) nommé config ou configure. Parfois, le fichier peut avoir une extension, telle que .sh (par exemple , config.sh). Il s'agit généralement d'un script shell qui exécute d'autres utilitaires pour confirmer que vous disposez d'un environnement "sain" pour la compilation. En d'autres termes, il vérifiera que vous avez installé tout ce dont vous avez besoin.

Astuce : Si c'est une application basée sur Python
application, au lieu d'un fichier de configuration,
vous devriez trouver un fichier nommé setup.py.
Les applications Python sont généralement très
simples à installer. Pour installer cette
application, en tant que root (par exemple, mettez sudo
devant la commande suivante
sous Ubuntu), exécutez cette commande :

    $ python setup.py install

Cela devrait être tout ce que vous avez à
faire. Vous pouvez sauter le reste de ce
tutoriel et passer directement à l'utilisation
et profiter de votre application.

Exécutez le script de configuration dans le terminal. Typiquement, vous pouvez (et devriez !) exécuter votre script de configuration avec votre compte utilisateur ordinaire.

$ ./config

Le script affichera quelques messages pour vous donner une idée de ce qu'il fait. Souvent, le script vous indiquera s'il a réussi ou échoué et, s'il a échoué, quelques informations sur la cause de l'échec. Si vous n'obtenez aucun message d'erreur, alors vous pouvez généralement supposer que tout s'est bien passé.

Si vous ne trouvez aucun script qui ressemble à un script de configuration, alors cela signifie généralement que l'application est très simple et qu'elle est indépendante de la plateforme. Cela signifie que vous pouvez simplement passer à l'étape de construction/compilation ci-dessous, parce que le script de configuration fourni. Makefile fourni devrait fonctionner sur n'importe quel système.

Un exemple

Dans ce tutoriel, je vais utiliser le lecteur RSS textuel appelé Newsbeuter comme un exemple pour les types d'erreurs que vous pouvez rencontrer lors de la construction de votre application. Pour Newsbeuter, le nom du script de configuration est le suivant . config.sh. Sur mon système, lorsque j'exécute config.sh, les erreurs suivantes se produisent :

[email protected]:~/download/newsbeuter-1.3$ ./config.sh
Checking for package sqlite3... not found

You need package sqlite3 in order to compile this program.
Please make sure it is installed.

En faisant quelques recherches, j'ai découvert qu'en fait, le programme sqlite3 était installée. Cependant, étant donné que j'essaie de construire à partir de la source, c'est une astuce qui ce que. config.sh cherche en fait les bibliothèques de développement (en-têtes) de l'application sqlite3. Dans Ubuntu, la plupart des paquets ont un paquet associé de contrepartie de développement qui se termine par -dev. (D'autres plates-formes, comme Fedora, utilisent souvent un suffixe de paquet de -devel pour les paquets de développement).

Pour trouver le paquet approprié pour la plate-forme sqlite3 paquet de développement, nous pouvons utiliser le apt-cache dans Ubuntu (et, de la même manière, l'utilitaire yum dans Fedora) :

[email protected]:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite

Cette commande renvoie une liste assez importante de résultats, nous devons donc faire un peu de travail de détective pour déterminer quel est le paquet approprié. Dans ce cas, le paquet approprié s'avère être libsqlite3-dev. Notez que parfois le paquet que nous recherchons aura le code lib au lieu d'avoir le même nom de paquet avec le préfixe -dev. Cela s'explique par le fait que parfois nous recherchons simplement une bibliothèque partagée qui peut être utilisée par de nombreuses applications différentes. Pour installer libsqlite3-dev, exécutez la commande typique apt-get install dans le terminal :

[email protected]:~/download/newsbeuter-1.3$ sudo apt-get install libsqlite3-dev

Maintenant, nous devons exécuter config.sh à nouveau pour s'assurer que nous avons résolu ce problème de dépendance et que nous n'avons pas d'autres problèmes de dépendance. (Bien que je ne le montrerai pas ici, dans le cas de Newsbeuter, j'ai également dû installer la commande libcurl4-openssl-dev .libcurl4-openssl-devégalement). De plus, si vous installez un paquet de développement (comme le paquet libsqlite3-dev) et le paquet d'application associé (par ex, sqlite3) n'est pas déjà installé, la plupart des systèmes installeront automatiquement le paquetage d'application associé en même temps.

Lorsque la configuration s'exécute avec succès, le résultat sera qu'elle créera un ou plusieurs fichiers make. Ces fichiers sont typiquement nommés Makefile (rappelez-vous que la casse des noms de fichiers compte sous Unix/Linux !). Si le paquetage de compilation comprend des sous-répertoires, tels que srcetc., chacun de ces sous-répertoires contiendra un fichier Makefile, ainsi que.

Erreurs de construction et de compilation

Maintenant, nous sommes prêts à compiler réellement l'application. Ceci est souvent appelé construction et le nom est emprunté au processus du monde réel de construire quelque chose. Les différents "morceaux" de l'application, qui sont généralement de multiples fichiers de code source, sont combinés ensemble pour former l'application globale. L'utilitaire make gère le processus de construction et appelle d'autres applications, comme le compilateur et l'éditeur de liens, pour effectuer le travail. Dans la plupart des cas, il vous suffit d'exécuter make (avec votre compte utilisateur habituel) à partir du répertoire où vous avez exécuté la configuration. (Dans quelques cas, comme la compilation d'applications écrites avec la bibliothèque Qt, vous devrez exécuter une autre application "wrapper" comme qmake à la place. Encore une fois, vérifiez toujours le paramètre README et/ou INSTALL pour plus de détails).

Comme avec le script de configuration ci-dessus, lorsque vous exécutez make (ou l'utilitaire similaire) dans le terminal, il affichera quelques messages sur ce qui est en train de s'exécuter et les avertissements et erreurs éventuels. Vous pouvez généralement ignorer les avertissements, car ils sont principalement destinés aux développeurs de l'application et leur indiquent que certaines pratiques standard sont violées. En général, ces avertissements n'affectent pas le fonctionnement de l'application. En revanche, les erreurs du compilateur doivent être traitées. Avec Newsbeuter, lorsque j'ai lancé make, tout s'est bien passé pendant un moment, mais j'ai ensuite eu une erreur :

[email protected]:~/download/newsbeuter-1.3$ make
...
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR="/usr/local/share/locale" -o src/configparser.o -c src/configparser.cpp
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR="/usr/local/share/locale" -o src/colormanager.o -c src/colormanager.cpp
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:5:18: error: stfl.h: No such file or directory
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:33: error: ISO C++ forbids declaration of u2018stfl_formu2019 with no type
./include/stflpp.h:33: error: expected u2018;u2019 before u2018*u2019 token
./include/stflpp.h:34: error: ISO C++ forbids declaration of u2018stfl_ipoolu2019 with no type
./include/stflpp.h:34: error: expected u2018;u2019 before u2018*u2019 token
make: *** [src/colormanager.o] Error 1

Le processus make s'arrêtera dès que la première erreur sera rencontrée. La gestion des erreurs du compilateur peut parfois être une affaire délicate. Vous devez regarder les erreurs pour trouver des indices sur le problème. Typiquement, le problème est que certains fichiers d'en-tête, qui ont généralement une extension de .h ou .hppsont manquants. Dans le cas de l'erreur ci-dessus, il est (ou devrait être !) clair que le problème est que stfl.h le fichier d'en-tête est introuvable. Comme le montre cet exemple, vous voulez regarder les premières lignes du message d'erreur et travailler vers le bas pour trouver la cause sous-jacente du problème.

Après avoir regardé la documentation de Newsbeuter (ce que j'aurais dû faire avant de commencer, mais alors cette partie du tutoriel n'aurait pas beaucoup de sens !), j'ai constaté qu'il nécessite une bibliothèque tierce appelée STFL. Alors que faisons-nous dans ce cas ? Eh bien, nous répétons essentiellement le même processus pour la bibliothèque requise : obtenir la bibliothèque et exécuter le processus configure-build-install pour elle et, ensuite, reprendre la construction de l'application désirée. Par exemple, dans le cas de STFL, j'ai dû installer la bibliothèque libncursesw5-dev pour qu'elle soit construite correctement. (Habituellement, il n'est pas nécessaire de refaire l'étape de configuration sur notre application originale après avoir installé une autre application requise, mais cela ne fait jamais de mal non plus).

Après avoir installé avec succès la boîte à outils STFL, le processus make pour Newsbeuter s'est exécuté avec succès. Le processus make reprend généralement là où il s'arrête (au point de l'erreur). Ainsi, tous les fichiers qui avaient déjà été compilés avec succès ne seront pas recompilés. Si vous voulez tout recompiler, vous pouvez exécuter make clean all pour supprimer tous les objets compilés et ensuite exécuter make à nouveau.

Installation de

Après que le processus de construction se termine avec succès, vous êtes prêt à installer l'application. Dans la plupart des cas, pour installer l'application dans les zones communes du système de fichiers (par ex, /usr/bin ou /usr/share/binetc.), vous devrez exécuter l'installation en tant que root. L'installation est vraiment l'étape la plus simple de tout le processus. Pour installer, dans le terminal, exécutez :

$ make install

Vérifiez la sortie de ce processus pour toute erreur. Si tout s'est déroulé avec succès, vous devriez être en mesure d'exécuter le nom de la commande dans le terminal et il sera lancé. (Ajoutez & à la fin de la ligne de commande, si c'est une application GUI, ou vous ne pourrez pas utiliser la session du terminal jusqu'à ce que l'application finisse de s'exécuter).

Lorsque vous construisez une application à partir des sources, elle n'ajoute généralement pas d'icône ou de raccourci aux menus de l'interface graphique dans Ubuntu. Vous devrez l'ajouter manuellement.

Et c'est essentiellement le processus, bien que potentiellement itératif, pour construire et installer une application à partir des sources dans Ubuntu. Après avoir fait cela juste quelques fois, cela deviendra une seconde nature pour vous !


Solution 4 :

Eh bien, ./configure --help vous donnera beaucoup d'informations, pour les fichiers configure générés par GNU autotools. La plupart se résume à --with/--without pour activer des fonctionnalités (celles-ci peuvent prendre un paramètre supplémentaire, comme "shared" pour dire où trouver la bibliothèque).

D'autres importants sont --prefix (qui par défaut est /usr/local/ la plupart du temps) pour dire où installer (si vous construisez des paquets, vous voulez généralement que ce soit --prefix=/usr ou peut-être --prefix=/opt/YourPackage).

Sous Linux, /lib, /usr/lib et /usr/local/lib sont généralement recherchés par gcc, et inclus dans la configuration par défaut de ldconfig. A moins que vous n'ayez une bonne raison, c'est là que vous devez placer vos bibliothèques. /etc/ld.so.conf peut cependant lister des entrées supplémentaires.

configure et make les trouvent en essayant simplement d'exécuter "gcc -l" et de voir s'il y a des erreurs. Vous pouvez ajouter "-L" à votre paramètre CFLAGS pour ajouter des chemins supplémentaires à rechercher.

Vous pouvez avoir plusieurs versions installées, et les logiciels liés contre une ancienne version resteront liés contre elle (exécutez ldd pour connaître la liaison sur Linux), mais les nouvelles compilations ciblent généralement la dernière version d'une bibliothèque dynamique sur votre système.

La plupart des logiciels supposent des librairies dynamiques, surtout s'ils utilisent libtool, donc vous pouvez trouver des applications non triviales qui ne se construisent pas correctement de manière statique.

ls -l est votre meilleur pari pour trouver les bibliothèques installées.

Et c'est là que je suis à court d'informations ; comment bien jouer avec les paquets : ne sais pas. Quand c'est possible, j'essaie d'emballer les choses dans un paquet pour éviter le problème.


Solution 5 :

Pour répondre un peu à votre question, j'ai trouvé l'autre jour un bon moyen de voir quelles bibliothèques vous avez installées et les versions (C'est sur Linux Debian donc cela devrait fonctionner aussi avec d'autres versions).

dpkg --list

Vous devriez obtenir une liste vraiment longue avec une sortie comme celle-ci.

ii  libssl0.9.8    0.9.8c-4etch5  SSL shared libraries
ii  libssp0        4.1.1-21       GCC stack smashing protection library
ii  libstdc++5     3.3.6-15       The GNU Standard C++ Library v3
ii  libstdc++5-3.3 3.3.6-15       The GNU Standard C++ Library v3 (development
ii  libstdc++6     4.1.1-21       The GNU Standard C++ Library v3

Nous vous montrons des avis et des notes

En bas de page vous pouvez retrouver les notes des autres chefs de projet, vous pouvez aussi montrer les vôtres si vous le souhaitez.



Utilisez notre moteur de recherche

Ricerca
Generic filters

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.