Pourquoi les librairies de paquet boost sont-elles installées dans / usr / lib / x86_64-linux-gnu?
Après avoir couru
Sudo apt-get install libboost-all-dev
sur le bureau ubuntu 14.04 AMD64 (Trusty Tahr), j’ai constaté que toutes les bibliothèques sont installées dans
/usr/lib/x86_64-linux-gnu/
au lieu de
/usr/lib/
Bien que tous les en-têtes soient toujours installés dans
/usr/include/
Pourquoi cela arrive-t-il?
Les packages de bibliothèque ont été créés sur plusieurs ordinateurs, ce qui signifie que vous pouvez installer simultanément la version AMD64 et la version i386 sur un ordinateur AMD64. Si vous souhaitez installer la version i386 d'une bibliothèque, ajoutez le nom du package à :i386. (Par exemple, Sudo apt-get install libboost-system1.54.0:i386)
Les paquetages de bibliothèque sont en train de devenir multi-architectures, ce qui facilite l'installation des paquetages d'autres architectures et l'exécution de programmes compilés pour d'autres architectures.
C'est par spec. Les en-têtes sont toujours un problème non résolu dans la spécification. et considéré hors du champ d’application comme indiqué dans le source sous la rubrique Problèmes non résolus
"Conception
Disposition du système de fichiers
Pour pouvoir intégrer de manière transparente plusieurs ABI ELF sur un système, la bibliothèque de chaque paire (soname, ABI) doit avoir un chemin unique sur le système de fichiers. La FHS tente de résoudre ce problème pour le cas AMD64 en exigeant que/usr/lib soit réservé aux bibliothèques 32 bits, avec des bibliothèques 64 bits situées dans/usr/lib64. Cette conception a un certain nombre d'inconvénients:
Cela n'est pas compatible avec les futures modifications ABI, ce qui nécessiterait des travaux de conception supplémentaires, ainsi que des modifications supplémentaires des packages pour gérer l'ajout de nouveaux chemins. (En effet, cela concerne déjà l'architecture MIPS, qui utilise trois ABI distinctes utilisées en parallèle.)
L'architecture AMD64 doit figurer dans l'emballage de la bibliothèque comme étant la seule architecture utilisant/usr/lib64 au lieu de/usr/lib. (Deux ports Linux 64 bits préexistants, Alpha et IA-64, utilisaient également/usr/lib pour leurs bibliothèques 64 bits.) Cette complexité est inutile.
Il n'aborde pas les cas d'utilisation de l'émulation, tels que qemu, qui pourraient s'intégrer beaucoup mieux et plus efficacement au système si les packages d'un qemu Arch étaient co-installables.
La conception actuelle utilisée par Debian et Ubuntu échoue également sur un point clé où la mise en page FHS ne le fait pas:
Le chemin d'accès aux bibliothèques x86 et x86-64 varie selon que le système est nativement en 32 bits ou en 64 bits. Par conséquent, la traduction des chemins au moment de l'installation est insuffisante pour le cas général, car certaines bibliothèques doivent incorporer des chemins de plug-in dans les fichiers binaires eux-mêmes.
Multiarch cherche à résoudre tous ces problèmes, au détriment d'une transition unique, en migrant les bibliothèques vers des sous-répertoires incluant le triplet d'architecture dans le chemin:
/ lib/i386-linux-gnu/lib/x86_64-linux-gnu/usr/lib/i386-linux-gnu/usr/lib/x86_64-linux-gnu "