Changer le répertoire des modules php

Je compile php, et son paramètre mon répertoire de modules sur / usr / lib64 / 20090626-zts

Je voudrais changer cela en / usr / lib64 / php / modules, mais je ne trouve pas d'option de configuration pour le faire.

Je peux le changer dans mon php.ini et déplacer le répertoire, mais quand je lance phpize et crée un nouveau module, il le met toujours dans / usr / lib64 / 20090626-zts

linux php

— copacétique
source

Ont pas eu le temps de tester ceci: EXTENSION_DIR=/usr/lib64/php/modules phpize.

— Mark Wagner

Réponses:

Je suggérerais de faire de / usr / lib64 / php / modules un lien symbolique vers le dossier avec l'ID. Cela empêche à long terme de mélanger les extensions de différentes versions de PHP.

En plus de cela: Vous devriez pouvoir le définir en définissant EXTENSION_DIRcomme variable d'environnement avant d'exécuter la configuration de PHP. quelque chose comme

 $ EXTENSION_DIR=/my/location ./configure --with-some-extension

— johannes
source

Oui, cela a du sens, je ne veux pas que mes modules entrent en conflit à l'avenir. Je pense que je vais simplement laisser le nom du dossier.

— 2011 copacétique

Vérifiez le répertoire d'extension actuel avec:

php-config --extension-dir

et vous pouvez le changer en mettant extension_diren php.ini:

extension_dir="/usr/lib64/php/modules"

N'oubliez pas de redémarrer Apache.

— quanta
source

Mon problème n'était pas identique, mais comme cette question a été la première à apparaître avec des réponses finalement très utiles, j'ajouterai mes commentaires.

J'avais du mal à obtenir que PHP (sous Centos7 fonctionnant dans un conteneur Docker) utilise MySQL en raison de la configuration du répertoire - bien que j'utilisais des binaires pré-construits et que je ne compile rien. Bien que les différents modules pdo et mysqlnd.so et les fichiers .ini aient été installés dans mon conteneur (en utilisant simplement la norme yum install php72et toutes les autres choses spécifiées dans l' assistant d'installation PHP ), ils n'étaient pas dans les emplacements par défaut que PHP recherchait. Je ne sais pas pourquoi. C'est peut-être une sorte de docker?

Quoi qu'il en soit, pour résoudre le problème, j'ai dû faire écho à une extension_dirdirective à mon PHP.iniet également définir la PHP_INI_SCAN_DIRvariable env. Ce sont les commandes pertinentes de mon Dockerfile

ENV PHP_INI_SCAN_DIR=/etc/php.d/
RUN echo 'extension_dir = "/usr/lib64/php/modules"' >> /etc/opt/remi/php72/php.ini

J'espère que cela n'entraînera pas de conflits de modules plus tard, comme l'avertit @johanes.

— charlesdeb
source

> "ils n'étaient pas dans les emplacements par défaut." Vous n'avez pas suivi correctement les instructions de l'assistant, en choisissant "version unique", tout est installé dans les emplacements par défaut. SCL utilise différents chemins pour autoriser plusieurs versions.

— Remi Collet

@RemiCollet merci pour la réponse. J'ai choisi une seule version de l'assistant - c'est ce que je pense que je veux puisque je ne veux qu'une seule version de PHP sur mon conteneur. La seule partie des instructions de l'assistant que je n'ai pas ajoutée dans mon dockerfile était `yum --enablerepo = remi-php72-test install php-xxx` et yum update. Est-ce que j'ai râté quelque chose?

— charlesdeb

Ces dernières commandes sont destinées aux packages de test et aux extensions supplémentaires (remplacez xxx par le nom de l'extension que vous souhaitez)

— Remi Collet

@RemiCollet Désolé, je dois être un peu stupide. Voulez-vous dire que si vous utilisez les packages de test, cela résoudra mon problème de modules mysql ne allant pas dans les .../remi/...dossiers?

— charlesdeb

Je dis que les paquets php- * (version unique) utilisent des chemins standard, et php72-php- * (SCL, plusieurs versions) utilisent / opt / remi. Voir blog.remirepo.net/pages/English-FAQ#scl

— Remi Collet