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

"Comment déterminer les arguments à passer à ./configure ?

habituellement : ./configure --help vous dira ce que vous voulez y trouver.

"Comment puis-je savoir quelles sont les bibliothèques que j'ai installées et quelles sont leurs versions ?

Cela dépend du système. Une solution consiste à faire un find /|grep libname|less car les fichiers de bibliothèque contiennent généralement la version dans le nom du fichier.

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

Là encore, cela dépend du système et de la bibliothèque. sudo make altinstall créera un nom versionné pour vous. Les fichiers de la bibliothèque se versionnent généralement eux-mêmes. Gardez cependant à l'esprit que les versions créent souvent des liens symboliques vers un nom "normalisé", ce qui peut perturber les choses.

"Si j'installe des choses à partir des sources sur un système qui est par ailleurs géré à l'aide de paquets, quelle est la manière la plus propre de le faire ?

En utilisant les paramètres --prefix dans ./configure et en les plaçant quelque part dans /opt est une bonne pratique à suivre.

Avis de non-responsabilité : Je ne suis en aucun cas un expert, mais j'utilise Linux depuis plus de 5 ans. à partir de la ligne cmd (slackware, CentOS, redhat, ubuntu, divers autres, et OS X).

Simon,

1.) ./configure --help fournit une bonne quantité d'informations. Je vous conseille de la consulter. Il y a généralement des options pour compiler les bibliothèques statiques/dynamiques lorsque c'est approprié.

2.) Les bibliothèques se trouvent dans le chemin d'accès de l'éditeur de liens dynamiques. Ce chemin est généralement défini dans le fichier /etc/ld.so.conf. L'éditeur de liens recherche les bibliothèques appropriées, tout comme la variable d'environnement PATH, en utilisant la première trouvée.

3.) Cela entraîne généralement des problèmes, car il faut tout recompiler lorsque la version d'une bibliothèque change. Si vous faites quelques recherches, vous trouverez probablement des tas de raisons pour lesquelles l'établissement de liens statiques est une mauvaise idée. Je ne l'ai pas fait depuis si longtemps que je ne peux pas vraiment développer ici.

4.) C'est un peu difficile. Les bibliothèques ont généralement un lien symbolique vers la version installée.

Par exemple, libssh2.so.1 -> libssh2.so.1.0.0

En général, les gens gèrent les bibliothèques et les programmes qu'ils installent en roulant leurs propres paquets debian ou en utilisant une autre technique. Je gère les logiciels installés en utilisant stow ( http://www.gnu.org/software/stow/ ) qui est très simple et installe la bibliothèque en utilisant des liens symboliques. Je trouve cela plus facile car je n'ai pas à construire/installer/tester un paquet deb/rpm.

5.) Plusieurs versions de bibliothèques peuvent être installées normalement dans les répertoires de bibliothèques. Les bibliothèques liées aux exécutables resteront liées aux versions auxquelles elles ont été liées. L'exécution de ldd sur un exécutable vous indiquera les bibliothèques auxquelles l'exécutable est lié.

6.) Comme je l'ai mentionné précédemment, rouler vos propres paquets debian ou utiliser stow est probablement la solution la plus propre.

7.) Je ne peux pas vraiment parler de Mac OSX, mais pour Linux, le système d'emballage de la distribution est le meilleur moyen.

8.) Il est probable qu'une grande partie de la frustration sera résolue en utilisant ldd et en découvrant quelle version est liée à quelque chose ou quelle bibliothèque est liée à un exécutable introuvable. pkg-config vous aidera beaucoup, mais seulement pour les logiciels qui l'utilisent. Il ne fait pas partie du système de construction par défaut d'autotools bien qu'il soit populaire ces jours-ci.

Les bibliothèques statiques ne sont pas une bonne idée : si vous devez mettre à jour la bibliothèque (pour corriger un problème de sécurité, par exemple), vous devrez recompiler tout ce qui dépend de cette bibliothèque.

Je n'aime pas l'idée que "make install" puisse potentiellement perturber mon système, mais comme d'autres l'ont dit, c'est généralement beaucoup moins pénible d'installer les choses dans /usr/local plutôt que d'utiliser --prefix pour les installer ailleurs. J'ai donc transféré /usr/local à mon utilisateur habituel (non privilégié). De cette façon, "make install" est à peu près sûr de ne pas perturber les fichiers importants du système. (Cela ne fonctionne évidemment pas sur les systèmes multi-utilisateurs. Mais c'est parfait pour les serveurs virtuels).

Bien que cela ne figure pas explicitement dans votre liste de questions, vous le mentionnez dans votre préface :

./configure && make && sudo make install suffit généralement, mais il arrive que cela ne fonctionne pas - et dans ce cas, je suis souvent bloqué.

Lorsque je suis bloqué sur Debian ou Ubuntu, j'utilise auto-apt qui installe automatiquement les paquets qui contiennent les fichiers que configure ne trouve pas.

Voir :

• http://www.debian.org/doc/manuals/apt-howto/ch-search.en.html#s-auto-apt
• https://help.ubuntu.com/community/AutoApt

CheckInstall est un autre outil qui peut s'avérer utile : il ajoute les applications installées à l'aide de make install à votre liste de paquets installés : https://help.ubuntu.com/community/CheckInstall

Pour OS X :

• Comment déterminer les arguments à passer à ./configure ?

./configure --help

• 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 ainsi éviter les conflits de versions de bibliothèques bizarres ?

L'utilisation de bibliothèques partagées vous permet de mettre à jour la bibliothèque sans recompiler tout ce qui l'utilise.

• Comment fonctionnent les bibliothèques partagées sous OS X / Linux - où elles se trouvent dans le système de fichiers, comment ./configure && make les trouve, ce qui se passe réellement lorsqu'elles sont liées.

Les bibliothèques du système se trouvent dans le répertoire /usr/lib.

Les bibliothèques que vous compilez vous-même se trouvent dans /usr/local/lib (/usr/local étant l'option --prefix par défaut de ./configure).

Les variables d'environnement DYLD_FALLBACK_LIBRARY_PATH et LD_LIBRARY_PATH vous permettent de spécifier dans quels dossiers chercher, ainsi /usr/local/lib devrait se trouver au début de la liste.

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

Installez tout dans /usr/local - avec les variables d'environnement ci-dessus, la version dans /usr/local/lib est prioritaire sur la version dans /usr/lib dans votre environnement.

• Si j'installe des choses à partir des sources sur un système qui est par ailleurs géré à l'aide de paquets, quelle est la manière la plus propre de le faire ?

Installer dans /usr/local. Dans Ubuntu, j'essaie d'utiliser checkinstall en premier, pour créer un paquet deb.

• En supposant que je parvienne à compiler quelque chose de compliqué à partir des sources, comment puis-je ensuite l'emballer pour que d'autres personnes n'aient pas à passer par les mêmes étapes ? En particulier sur OS X....

Documenter les étapes de la compilation dans un article de blog, je dirais.