Solution 1 :
Je m'excuse de répondre directement à tout, mais je ne connais pas de tutoriels utiles, de FAQ, etc.
Pratique vraiment. Autotools est assez facile car il est cohérent. Mais il y a beaucoup de choses qui utilisent cmake ou des scripts de construction personnalisés. Généralement, vous ne devriez pas avoir à passer quoi que ce soit pour configurer, il devrait déterminer si votre système peut construire foo-tool ou non.
Configure et les outils GNU recherchent tous les dépendances dans /, /usr et /usr/local. Si vous installez quoi que ce soit ailleurs (ce qui rend les choses pénibles si la dépendance a été installée par MacPorts ou Fink), vous devrez passer un drapeau pour configurer ou modifier l'environnement du shell pour aider les outils GNU à trouver ces dépendances.
Sous Linux, ils doivent être installés sur un chemin que l'éditeur de liens dynamique peut trouver, ceci est défini par le LD_LIBRARY_PATH variable d'environnement et le contenu de /etc/ld.conf. Sur Mac, c'est presque toujours la même chose pour la plupart des logiciels open source (sauf s'il s'agit d'un projet Xcode). Sauf que la variable env est DYLD_LIBRARY_PATH à la place.
Il existe un chemin par défaut dans lequel l'éditeur de liens recherche 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 nombre d'autres variables d'environnement vraiment (commodément compliquées). Je suggère CFLAGS comme ceci :
export CFLAGS="$CFLAGS -L/nouveau/chemin"
Le paramètre -L s'ajoute au chemin du lien.
Les trucs modernes utilisent l'outil pkg-config. Les éléments modernes que vous installez installent également un fichier .pc décrivant la bibliothèque, son emplacement et la manière de s'y connecter. Cela peut rendre la vie plus facile. Mais il n'est pas fourni avec OS X 10.5, vous devrez donc l'installer également. De plus, de nombreux services de base ne le prennent pas en charge.
L'acte de liaison consiste simplement à "résoudre cette fonction au moment de l'exécution", c'est vraiment une grande table de chaînes.
Lorsque vous créez un lien vers 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 créer un lien statique vers tout, cependant, malheureusement, presque aucun système de construction ne facilite cela. Vous devrez modifier manuellement les fichiers système de construction (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 des dépendances en parallèle.
L'astuce consiste à changer la ligne de lien de -lfoo à -l/path/to/static/foo.a
Vous pouvez probablement trouver et remplacer. Ensuite, vérifiez que l'outil n'est pas lié au .so ou dylib en utilisant ldd foo ou otool -L foo
Un autre problème est que toutes les bibliothèques ne se compilent pas en bibliothèques statiques. Beaucoup le font. Mais alors MacPorts ou Debian ont peut-être décidé de ne pas le livrer.
Si vous avez des fichiers pkg-config pour ces bibliothèques, c'est simple :
pkg-config --list-all
Sinon, vous ne pouvez souvent pas facilement. Le dylib peut avoir un soname (c'est-à-dire 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 requis. Le soname est une fonctionnalité de calcul binaire, vous devez remplacer la majeure partie du soname si vous changez le format des fonctions dans la bibliothèque. Ainsi, vous pouvez obtenir par exemple. version 14.0.5 soname pour une bibliothèque 2.0. Bien que ce 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.
Ma solution à cela est ici :http://github.com/mxcl/homebrew/
J'aime installer à partir des sources et je voulais un outil qui facilite les choses, mais avec une certaine gestion des packages. Donc, avec Homebrew, je construis, par exemple. wget me depuis la source, mais assurez-vous d'installer avec un préfixe spécial :
/usr/local/Cave/wget/1.1.4
J'utilise ensuite l'outil homebrew pour lier symboliquement tout cela dans /usr/local, donc 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 simplement changer la version qui est liée à l'arborescence /usr/local.
Je pense que la méthode Homebrew est la plus propre, alors utilisez-la ou faites l'équivalent. Installez dans /usr/local/pkgs/name/version et un lien symbolique ou un lien physique pour le reste.
Utilisez /usr/local. Chaque outil de construction existant y recherche des dépendances et des en-têtes. Votre vie sera beaucoup plus facile.
S'il n'a pas de dépendances, vous pouvez tarer le répertoire de construction et le donner à quelqu'un d'autre qui pourra alors faire "make install". Cependant, vous ne pouvez le faire de manière fiable que pour les mêmes versions exactes d'OS X. Sous Linux, cela fonctionnera probablement pour Linux similaire (par exemple, Ubuntu) avec la même version du noyau et la version mineure de la libc.
La raison pour laquelle il n'est pas facile de distribuer des binaires sur Unix est la compatibilité binaire. Les gens de GNU, et tout le monde changent souvent leurs interfaces binaires.
Fondamentalement, ne distribuez pas de binaires. Les choses vont probablement se casser de manière très étrange.
Sur Mac, la meilleure option est de créer un package macports. Tout le monde utilise macports. Sous Linux, il existe tellement de systèmes de construction et de combinaisons différents, je ne pense pas qu'il y ait de meilleur conseil que d'écrire une entrée de blog sur la façon dont vous avez réussi à construire x outil dans une configuration étrange.
Si vous faites une description de package (pour macports ou homebrew), n'importe qui peut installer ce package, et cela résout également les problèmes de dépendance. Cependant, ce n'est souvent pas facile, et il n'est pas non plus facile d'inclure votre recette de macports dans l'arborescence principale des macports. De plus, macports ne prend pas en charge les types d'installation exotiques, ils offrent un choix pour tous les packages.
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 package, puis créera l'application. Mais oui, pas encore fait, mais pas trop compliqué compte tenu du design que j'ai choisi.
otool n'est vraiment utile qu'après. Il vous indique à quoi sont liés les binaires construits. Lorsque vous déterminez les dépendances d'un outil que vous devez créer, cela ne sert à rien. 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 consiste à lire les fichiers README et INSTALL et à effectuer un configure --help. Regardez la sortie de la construction pour vérifier qu'elle est saine. Analysez toutes les erreurs de construction. Peut-être à l'avenir, demandez sur serverfault :)
Solution 2 :
C'est un sujet énorme alors 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 (objets partagés dynamiques) qui couvre un peu l'histoire des bibliothèques partagées sur Linux disponibles ici, y compris pourquoi ils sont importants
Ulrich décrit également pourquoi les liens statiques sont considérés comme nuisibles. L'un des points clés ici concerne les mises à jour de sécurité. Les débordements de tampon dans une bibliothèque commune (par exemple zlib) qui est largement liée statiquement peuvent entraîner une surcharge énorme pour les distributions - cela s'est produit avec zlib 1.1.3 (avis 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 glob include 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 tutoriel DSO devrait vous donner un bon niveau de connaissances de base afin de comprendre ensuite comment ces principes s'appliquent à Mach-O sur OS X.
Mach-O
Sur OS X, le format binaire est Mach-O. La documentation système locale pour l'éditeur de liens est
man dyld
La documentation du format Mach est disponible auprès d'Apple
Outils de compilation UNIX
Le configure commun , make , make install Le processus 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 piloter cela. Automake est essentiellement une méthode de création de modèles pour les Makefiles, le modèle étant généralement appelé Makefile.am qui génère un Makefile.in que la sortie d'autoconf (le script de configuration) convertit en un Makefile.
Le programme GNU hello est un bon exemple pour comprendre la chaîne d'outils GNU - et le manuel inclut la documentation des autotools.
Solution 3 :
Simon! Je sais ce que tu ressens; J'ai également eu du mal avec cette partie de l'apprentissage de Linux. Sur la base de mes propres expériences, j'ai écrit un tutoriel sur certains des éléments que vous abordez (principalement comme 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é des applications Python à construire/installer. :)
J'espère que cela aide! Et bonne compilation.
Tim Jones
Construire/Installer une application à partir de la source dans Ubuntu Linux
Bien que les référentiels Ubuntu regorgent d'excellentes applications, à un moment ou à un autre, vous rencontrerez forcément cet outil "indispensable" qui ne se trouve pas dans les référentiels (ou qui n'a pas de paquet Debian) ou vous avez besoin d'un version plus récente que dans les référentiels. Que fais-tu? Eh bien, vous devez créer l'application à partir des sources ! Ne vous inquiétez pas, ce n'est vraiment pas aussi compliqué qu'il y paraît. Voici quelques conseils, basés sur mes expériences de devenir un amateur de rang ! (Bien que j'utilise Ubuntu pour cet exemple, les concepts généraux devraient être applicables à la plupart des distributions Unix/Linux, telles que Fedora, et même la plate-forme Cygwin sous Windows.)
Le processus de base de construction (compilation) de la plupart des applications à partir des sources suit cette séquence :configure --> compile --> install. Les commandes Unix/Linux typiques pour faire ces choses sont :config --> make --> make install . Dans certains cas, vous trouverez même des pages Web qui montrent que tout cela peut être combiné 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é d'application à partir des sources sur votre système auparavant, vous devrez probablement la configurer avec des outils de développement généraux, tels que le gcc suite de compilateurs, certains fichiers d'en-tête communs (considérez 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 installera de ceci. Pour l'installer (ou simplement vous 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 source de l'application et enregistrez-les dans un répertoire pour lequel vous disposez d'autorisations de lecture/écriture, tel que votre répertoire "home". En règle générale, ceux-ci seront dans un fichier d'archive avec l'extension de fichier soit .tar.gz ou .tar.bz2 . Le .tar signifie simplement qu'il s'agit d'une "archive sur bande", qui est un regroupement de fichiers qui préserve leur structure de répertoire relative. Le .gz signifie gzip (GNU zip), qui est un format de compression Unix/Linux populaire. De même, le .bz2 signifie bzip2, qui est un format de compression plus récent qui offre une compression plus élevée (taille de fichier compressée plus petite) que gzip.
Après avoir téléchargé le fichier source, ouvrez une fenêtre de terminal (Terminal système dans le menu Ubuntu) et accédez au répertoire dans lequel vous avez enregistré votre fichier. (J'utiliserai ~/download dans cet exemple. Ici, '~' est un raccourci vers votre répertoire "home".) Utilisez la commande tar pour extraire les fichiers du fichier d'archive téléchargé :
Si votre fichier est une archive gzip (par exemple, 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
Astuce :Si vous ne voulez pas avoir à vous souvenir de tous les commutateurs de ligne de commande pour extraire les archives, je vous 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 utilitaires, il vous suffit d'entrer le nom de l'utilitaire (dtrx ou deco) et le nom du fichier, il fait tout le reste. Ces deux "sont" comment gérer la plupart des formats d'archives que vous êtes susceptible de rencontrer et ils ont une excellente gestion des erreurs.
Lors de la compilation à partir de la source, vous êtes susceptible de rencontrer deux types d'erreurs courants :
- Des 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.
- Des erreurs de compilation se produisent lorsque vous exécutez la commande make (après la génération du makefile) et que le compilateur est incapable de trouver le code dont il a besoin.
Nous examinerons chacun de ces problèmes et discuterons de la manière 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 contenant les fichiers extraits. Typiquement, ce nom de répertoire sera le même que le nom du fichier (sans le .tar.gz ou .tar.bz2 extension). Cependant, parfois, le nom du répertoire est simplement le nom de l'application, sans aucune information sur la version.
Dans le répertoire source, recherchez un README fichier et/ou un INSTALL fichier (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, y compris des informations sur les dépendances. Les "dépendances" ne sont qu'un nom fantaisiste pour d'autres composants ou bibliothèques nécessaires à une compilation réussie.
Après avoir lu le README et/ou INSTALL fichier (et, espérons-le, consulté toute documentation en ligne pertinente pour l'application), recherchez un fichier exécutable (avec l'autorisation "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 :S'il s'agit d'une application basée sur Python, au lieu d'un fichier de configuration, vous devriez trouver un fichier nommé
setup.pyLes applications .Python sont généralement très simples à installer. Pour installer cette application, en tant que root (par exemple, placez sudo devant la commande suivante sous Ubuntu), exécutez cette commande :$ python setup.py installCela devrait être tout ce que vous devez faire. Vous pouvez ignorer le reste de ce didacticiel et passer directement à l'utilisation et à l'utilisation de votre application.
Exécutez le script de configuration dans le terminal. En règle générale, vous pouvez (et devriez !) exécuter votre script de configuration avec votre compte d'utilisateur habituel.
$ ./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é, des informations sur la cause de l'échec. Si vous ne recevez aucun message d'erreur, vous pouvez généralement supposer que tout s'est bien passé.
Si vous ne trouvez aucun script qui ressemble à un script de configuration, cela signifie généralement que l'application est très simple et qu'elle est indépendante de la plate-forme. Cela signifie que vous pouvez simplement passer à l'étape de construction/compilation ci-dessous, car le Makefile fourni devrait fonctionner sur n'importe quel système.
Un exemple
Dans ce didacticiel, je vais utiliser le lecteur RSS textuel appelé Newsbeuter comme exemple pour les types d'erreurs que vous pouvez rencontrer lors de la création de votre application. Pour Newsbeuter, le nom du script de configuration est 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.
Après quelques recherches, j'ai découvert qu'en fait, le sqlite3 l'application a été installée. Cependant, puisque j'essaie de construire à partir de la source, c'est une astuce que ce config.sh recherche actuellement les bibliothèques de développement (en-têtes) pour sqlite3 . Dans Ubuntu, la plupart des packages ont un package homologue de développement associé qui se termine par -dev . (D'autres plates-formes, telles que Fedora, utilisent souvent un suffixe de package de -devel pour les packages de développement.)
Pour trouver le package approprié pour le sqlite3 package de développement, nous pouvons utiliser le apt-cache utilitaire dans Ubuntu (et, de même, le yum utilitaire dans Fedora):
[email protected]:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite
Cette commande renvoie une assez longue liste de résultats, nous devons donc faire un peu de travail de détective pour déterminer quel est le package approprié. Dans ce cas, le package approprié s'avère être libsqlite3-dev . Notez que parfois le paquet que nous recherchons aura le lib préfixe, au lieu du même nom de package plus -dev . En effet, nous recherchons parfois simplement une bibliothèque partagée pouvant ê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 encore une fois pour nous assurer que nous avons résolu ce problème de dépendance et que nous n'avons plus de problèmes de dépendance. (Bien que je ne le montre pas ici, dans le cas de Newsbeuter, j'ai également dû installer le libcurl4-openssl-dev package également.) En outre, si vous installez un package de développement (comme libsqlite3-dev ) et le package d'application associé (par exemple, sqlite3 ) n'est pas déjà installé, la plupart des systèmes installeront automatiquement le package 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 généralement nommés Makefile (rappelez-vous que la casse des noms de fichiers est importante sous Unix/Linux !). Si le package de construction inclut des sous-répertoires, tels que src , etc., chacun de ces sous-répertoires contiendra un Makefile , ainsi.
Erreurs de compilation et de compilation
Maintenant, nous sommes prêts à réellement compiler l'application. C'est ce qu'on appelle souvent la construction et le nom est emprunté au processus réel de construction de quelque chose. Les différents "morceaux" de l'application, qui sont généralement plusieurs fichiers de code source, sont combinés pour former l'application globale. L'utilitaire make gère le processus de construction et appelle d'autres applications, telles que le compilateur et l'éditeur de liens, pour effectuer le travail. Dans la plupart des cas, vous exécutez simplement make (avec votre compte d'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 README et/ou INSTALL documents 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 des messages sur ce qui est en cours d'exécution et sur les avertissements et les erreurs. 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 enfreintes. Généralement, ces avertissements n'affectent pas le fonctionnement de l'application. D'autre part, les erreurs de compilation doivent être traitées. Avec Newsbeuter, quand j'ai exécuté make, les choses se sont bien passées 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_form\u2019 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_ipool\u2019 with no type
./include/stflpp.h:34: error: expected \u2018;\u2019 before \u2018*\u2019 token
make: *** [src/colormanager.o] Error 1
Le processus de création s'arrêtera dès que la première erreur sera rencontrée. La gestion des erreurs de compilation peut parfois être délicate. Vous devez regarder les erreurs pour quelques indices sur le problème. Généralement, le problème est que certains fichiers d'en-tête, qui ont généralement l'extension .h ou .hpp , sont manquantes. Dans le cas de l'erreur ci-dessus, il est (ou devrait être !) clair que le problème est que stfl.h fichier d'en-tête introuvable. Comme le montre cet exemple, vous souhaitez examiner les premières lignes du message d'erreur et progresser pour trouver la cause sous-jacente du problème.
Après avoir consulté la documentation de Newsbeuter (ce que j'aurais dû faire avant de commencer, mais cette partie du didacticiel ne serait pas très significative !), J'ai découvert qu'elle nécessitait une bibliothèque tierce appelée STFL. Alors que fait-on dans ce cas ? Eh bien, nous répétons essentiellement ce même processus pour cette bibliothèque requise :obtenez la bibliothèque et exécutez le processus de configuration-construction-installation pour celle-ci, puis reprenez la construction de l'application souhaitée. Par exemple, dans le cas de STFL, j'ai dû installer le libncursesw5-dev package pour qu'il se construise correctement. (Habituellement, il n'est pas nécessaire de refaire l'étape de configuration sur notre application d'origine 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 de création de Newsbeuter s'est exécuté avec succès. Le processus de création reprend généralement là où il s'est arrêté (au moment de l'erreur). Ainsi, tous les fichiers déjà 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, puis relancer make.
Installation
Une fois le processus de génération terminé, 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 exemple, /usr/bin ou /usr/share/bin , etc.), 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, lancez :
$ make install
Vérifiez la sortie de ce processus pour toute erreur. Si tout a réussi, vous devriez pouvoir exécuter le nom de la commande dans le terminal et il se lancera. (Ajoutez &à la fin de la ligne de commande, s'il s'agit d'une application graphique, sinon vous ne pourrez pas utiliser la session de terminal tant que l'application n'aura pas fini de s'exécuter.)
Lorsque vous créez une application à partir de la source, 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, de création et d'installation d'une application à partir de la source dans Ubuntu. Après avoir fait cela quelques fois, cela deviendra une seconde nature pour vous !
Solution 4 :
Eh bien, ./configure --help vous donnera beaucoup d'informations, pour les fichiers de configuration générés par les autotools GNU. La plupart d'entre elles se résument à --with/--without pour activer les fonctionnalités (celles-ci peuvent prendre un paramètre supplémentaire, comme "partagé" pour indiquer où trouver la bibliothèque).
D'autres importants sont --prefix (qui par défaut est /usr/local/ la plupart du temps) pour indiquer où installer (si vous construisez des packages, vous le voulez généralement comme --prefix=/usr ou peut-être --prefix =/opt/VotrePackage).
Sous Linux, /lib, /usr/lib et /usr/local/lib sont généralement recherchés dans gcc et inclus dans la configuration par défaut de ldconfig. Sauf si vous avez une bonne raison, c'est là que vous voulez vos bibliothèques. /etc/ld.so.conf peut cependant lister des entrées supplémentaires.
configurez et faites-les trouver en essayant simplement d'exécuter "gcc -l" et de voir s'il y a une erreur. 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 à une ancienne version resteront liés à celle-ci (exécutez ldd pour connaître la liaison sous 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 bibliothèques dynamiques, en particulier s'ils utilisent libtool, vous pouvez donc constater que des applications non triviales 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 n'ai plus d'informations ; comment bien jouer avec les packages :je ne sais pas. Lorsque c'est possible, j'essaie de regrouper les choses dans un package 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 également fonctionner avec d'autres versions).
dpkg --list
Vous devriez obtenir une très longue liste 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