GNU/Linux >> Tutoriels Linux >  >> Linux

Où puis-je placer des bibliothèques tierces pour configurer un environnement de développement C++ Linux ?

Où placer les bibliothèques

La meilleure solution est d'utiliser le système de packaging de votre distribution Linux (apt-get , yum , ou similaire) pour installer des bibliothèques à partir de packages fournis par la distribution dans la mesure du possible.

Si les bibliothèques packagées de la distribution ne sont pas d'une version suffisamment récente, ou si vous avez besoin d'options de construction non standard, ou si vous avez besoin d'une bibliothèque que votre distribution ne fournit pas, vous pouvez la construire et l'installer vous-même. Vous avez deux options principales pour savoir où placer la bibliothèque :

  • /usr/local (bibliothèques sous /usr/local/lib , en-têtes sous /usr/local/include ). Cela installe les bibliothèques à l'échelle du système et est probablement la solution la plus simple, puisque vous devriez alors pouvoir construire avec elles sans prendre d'étapes supplémentaires. N'installez PAS les bibliothèques directement sous /usr , car cela interférera avec le système d'empaquetage de votre distribution.
  • Sous le répertoire de votre projet, comme vous l'avez fait sous Windows. Cela présente les avantages de ne pas nécessiter d'accès root et de ne pas apporter de modifications à l'échelle du système, mais vous devrez mettre à jour les chemins d'inclusion et les chemins de bibliothèque de votre projet, et vous devrez placer tous les fichiers de bibliothèque partagés quelque part où l'éditeur de liens dynamique peut les trouver ( en utilisant LD_LIBRARY_PATH ou ld.so.conf - voir le lien pour plus de détails).

Fonctionnement des bibliothèques

Voir l'excellent HOWTO de la bibliothèque de programmation de David A. Wheeler. Je vous recommande de lire cela, puis de publier des questions spécifiques en tant que nouveaux sujets.

Comment distribuer votre programme

Traditionnellement, les programmes Unix/Linux n'incluent pas de copies de leurs dépendances. C'est plutôt à l'utilisateur final ou au développeur d'installer ces dépendances eux-mêmes. Cela peut nécessiter un "large README", comme vous l'avez dit, mais cela présente quelques avantages :

  • Les bibliothèques de développement peuvent être installées, gérées et mises à jour via le gestionnaire de packages de la distribution, au lieu que chaque copie source ait son propre ensemble de bibliothèques à suivre.
  • Il n'y a qu'une seule copie d'une bibliothèque donnée sur un système, donc il n'y a qu'un seul endroit qui doit être mis à jour si, par exemple, une faille de sécurité est découverte. (Par exemple, considérez le chaos qui a résulté lorsque zlib, une bibliothèque de compression très utilisée, s'est avérée avoir une faille de sécurité, de sorte que chaque application qui comprenait une version affectée devait être mise à jour.)
  • Si votre programme est assez populaire (et qu'il est open source ou au moins disponible gratuitement), alors les mainteneurs de packages pour diverses distributions Linux voudront peut-être l'empaqueter et l'inclure dans leur distribution. Les mainteneurs de paquets vraiment n'aime pas les bibliothèques groupées. Voir, par exemple, la page de Fedora sur le sujet.

Si vous distribuez votre programme aux utilisateurs finaux, vous pouvez envisager d'offrir un package (.dpkg ou .rpm ) qu'ils pouvaient simplement télécharger et installer sans avoir à utiliser la source. Idéalement, du point de vue de l'utilisateur final, le package serait ajouté aux référentiels des distributions (s'il est open source ou au moins disponible gratuitement) afin que les utilisateurs puissent le télécharger à l'aide de leurs gestionnaires de packages (apt-get ou yum ). Tout cela peut devenir compliqué, en raison du grand nombre de distributions Linux, mais un .dpkg compatible Debian/Ubuntu et un .rpm compatible Red Hat/CentOS/Fedora devrait couvrir un bon pourcentage d'utilisateurs finaux. Construire des packages n'est pas trop difficile et il existe de bons tutoriels en ligne.


pour la première partie de votre question concernant Windows :il n'y a pas de véritable place standard pour les bibliothèques/en-têtes sur Windows, donc la solution la plus simple est :créez la vôtre. Fournissez simplement un seul lib/ et include/ sur votre système et faites en sorte que tous vos projets l'utilisent (en définissant le chemin dans un fichier cmake que vous incluez partout). Mettez-y toutes les bibliothèques tierces, par exemple :

vos projets :

d:/projects/projectA
d:/projects/projectB

trucs tiers :

d:/api/lib/lua.lib
d:/api/include/lua/....

(vous pouvez même utiliser des liens symboliques appelés "jonctions de répertoires" si vous avez une version différente)

et le fichier cmake correspondant :

include_directories( d:/api/include )
link_directories( d:/api/lib )

Linux
  1. Un guide pour comprendre les bibliothèques de logiciels Linux en C

  2. Termux transforme Android en environnement de développement Linux

  3. Comment définir/créer des variables d'environnement et de shell sous Linux

  4. Bibliothèque partagée dynamique C++ sous Linux

  5. Comment configurer googleTest en tant que bibliothèque partagée sous Linux

Comment définir et répertorier les variables d'environnement sous Linux

Configurer l'environnement de développement WordPress local sous Linux

Comment définir et supprimer des variables d'environnement sous Linux

Linux - Où la chaîne d'environnement est-elle réellement stockée ?

Où les variables d'environnement doivent-elles être définies pour Jenkins ?

Configuration d'un environnement de développement brillant sous Linux sur Windows 10