Lors de la construction de Python sur Linux, il existe une option de configuration appelée --enable-shared, donc je vais l'expliquer et vous donner quelques conseils.
J'ai donné Python comme exemple concret, mais je pense que la plupart du contenu est commun à d'autres langages et bibliothèques.
Si vous ne spécifiez pas cette option, vous aurez un fichier exécutable appelé python et un fichier de bibliothèque appelé libpython2.7.a (pour Python 2.7) comme fichiers binaires principaux.
Si vous ajoutez --enable-shared, un objet partagé pour le lien dynamique appelé libpython2.7.so est également généré, et python liera dynamiquement cet objet partagé.
Les distributions Linux telles que Debian construisent généralement Python avec cette option. C'est parce que de nombreux programmes sont construits pour utiliser Python, et si vous liez directement libpython2.7.a, vous devrez tous les mettre à jour lorsque vous mettez à jour Python.
Je ne recommande pas --enable-shared car si vous construisez vous-même Python, cet avantage ne prend pas vraiment vie, mais peut plutôt être ennuyeux pour quiconque souhaite utiliser plusieurs versions en parallèle. À moins que vous ne souhaitiez utiliser un objet partagé pour une raison quelconque, vous n'avez pas à lire le reste.
Lorsqu'un fichier exécutable python ou un programme qui lie Python en tant que bibliothèque, tel que mod_wsgi, devient dépendant de libpython2.7.so, le programme en cours d'exécution sera libpython2.7.so comme prévu. Il est possible que vous n'utilisiez pas.
Par exemple, si vous construisez et installez avec --prefix = / usr / local / Python-2.7.3, vous pouvez exécuter / usr / local / Python-2.7.3 / bin / python pour définir et les variables d'environnement. Selon la situation, / usr / lib / libpython2.7.so ou / usr / local / Python-2.7.2 / lib / libpython2.7.so peut être utilisé.
Vous pouvez utiliser la variable d'environnement LD_LIBRARY_PATH pour spécifier l'emplacement de la bibliothèque à charger de préférence, mais si vous utilisez plusieurs versions de Python en parallèle, il est difficile de changer vous-même la variable d'environnement. Si quelqu'un d'autre utilise le même serveur, cette personne peut être confuse.
C'est peut-être une approche simple.
L'emplacement de la liaison libpython2.7.so sera enregistré avec le chemin complet du côté qui crée le lien dynamique, comme le fichier exécutable python.
Pour définir le rpath, il est facile de spécifier LDFLAGS lors de la configuration.
$ ./configure --prefix=$HOME/python27 --enable-shared \
LDFLAGS=-Wl,-rpath,$HOME/python27/lib
Le seul inconvénient de l'utilisation de rpath est la portabilité de la copie de l'intégralité de Python dans un autre répertoire avec cp -r etc. et de la réécriture du shebang dans le script dans bin /. Dans virtualenv, si libpython2.7.so est à l'emplacement d'origine, cela continuera à fonctionner, donc il n'y a pas de problème, mais si vous utilisez virtualenv, vous ne savez pas combien de temps l'ancienne version de Python est utilisée et vous ne voulez pas l'effacer, alors copiez le tout Il n'est pas recommandé aux personnes qui souhaitent l'utiliser.
Si vous avez besoin d'un objet partagé dans un but précis, mais que l'exécutable python n'a pas besoin de le lier dynamiquement, il existe un moyen de lier libpython2.7.a lors de la construction de python. .. Pour ce faire, ouvrez Makefile après avoir configuré et
BLDLIBRARY= -L. -lpython$(VERSION)
Où est-ce que c'est
BLDLIBRARY= libpython$(VERSION).a
Je vais le réécrire.
Le paquet Debian python semble être construit de la même manière, avec libpython2.7.so, mais python lie statiquement libpython. La raison semble être que l'objet partagé était PIC et avait de mauvaises performances. (C'est aussi la raison pour laquelle vim ne peut pas utiliser Python 2 et 3 en même temps)
Recommended Posts