PHP 5.3.0 des difficultés à installer avec intl-support
https://stackoverflow.com/questions/1078412
-
21-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Actuellement, je suis en train d'installer PHP 5.3.0 sur un serveur de test Linux. Comme nous l'avons attendu d'urgence ext / intl nous voulons vérifier les fonctionnalités qu'il offre.
Je suis en cours d'exécution avec succès avec les configure arguments suivants
./configure
--with-apxs2=/usr/local/apache2/bin/apxs
--prefix=/usr/local/php
--with-zlib-dir=/usr/local/zlib
--with-imap=/.../imap-2006k
--with-imap-ssl
--with-openssl=shared
--with-iconv=shared
--with-zlib=shared
--with-curl=shared
--with-curlwrappers
--enable-exif
--with-ldap=shared,/usr/local/openldap
--with-ldap-sasl
--enable-mbstring=shared
--with-mcrypt
--enable-soap=shared
--enable-sockets
--enable-zip=shared
--enable-pdo=shared
--with-pdo-sqlite=shared
--with-sqlite=shared
--with-mysql=shared,/usr/local/mysql
--with-pdo-mysql=shared,/usr/local/mysql
--with-mysqli=shared,/usr/local/mysql/bin/mysql_config
--with-mhash=shared,/usr/local/mhash
--with-libxml-dir=/usr/local/libxml2
--with-xsl=shared,/usr/local/libxslt
--enable-xmlreader=shared
--enable-xmlwriter=shared
--with-gmp=shared
--with-icu-dir=/usr/local/icu
--enable-intl
ICU 4.2 est situé à PHP 5.2.9 et /usr/local/icu compilé parfaitement (sans les INT- et ICU options). Mais quand je complie la source PHP 5.3.0 Je reçois beaucoup de messages d'erreur du type
ext/intl/grapheme/.libs/grapheme_util.o(.text+0xbab):/.../php-5.3.0/ext/intl/grapheme/grapheme_util.c:208: undefined reference to `ubrk_close_4_2'
Je suis tout à fait sûr qu'il a quelque chose à voir avec ne pas trouver les bibliothèques partagées. Réglage
export LD_LIBRARY_PATH=/usr/local/icu/lib
ne contribue pas.
Quelqu'un peut-il me pointer vers une solution? Je suis plutôt désemparés - et je ne suis pas expert réel dans ces choses ...
EDIT:
Je viens revérifié et fait en sorte que les différentes bibliothèques ICU et les liens souples respectifs sont tous situés dans /usr/local/icu/lib:
lrwxrwxrwx 1 root root 20 Jul 1 09:56 libicudata.so -> libicudata.so.42.0.1
lrwxrwxrwx 1 root root 20 Jul 1 09:56 libicudata.so.42 -> libicudata.so.42.0.1
-rw-r--r-- 1 root root 16015140 Jul 1 09:56 libicudata.so.42.0.1
lrwxrwxrwx 1 root root 20 Jul 1 09:56 libicui18n.so -> libicui18n.so.42.0.1
lrwxrwxrwx 1 root root 20 Jul 1 09:56 libicui18n.so.42 -> libicui18n.so.42.0.1
-rwxr-xr-x 1 root root 2454770 Jul 1 09:56 libicui18n.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicuio.so -> libicuio.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicuio.so.42 -> libicuio.so.42.0.1
-rwxr-xr-x 1 root root 65299 Jul 1 09:56 libicuio.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicule.so -> libicule.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicule.so.42 -> libicule.so.42.0.1
-rwxr-xr-x 1 root root 356125 Jul 1 09:56 libicule.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libiculx.so -> libiculx.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libiculx.so.42 -> libiculx.so.42.0.1
-rwxr-xr-x 1 root root 75110 Jul 1 09:56 libiculx.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicutu.so -> libicutu.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicutu.so.42 -> libicutu.so.42.0.1
-rwxr-xr-x 1 root root 159330 Jul 1 09:56 libicutu.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicuuc.so -> libicuuc.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicuuc.so.42 -> libicuuc.so.42.0.1
-rwxr-xr-x 1 root root 1660769 Jul 1 09:56 libicuuc.so.42.0.1
make check exécute des tonnes de tests - tous avec succès:
[All tests passed successfully...]
Elapsed Time: 00:00:25.000
make[2]: Leaving directory `/.../icu-4.2/source/test/cintltst'
---------------
ALL TESTS SUMMARY:
All tests OK: testdata intltest iotest cintltst
make[1]: Leaving directory `/.../icu-4.2/source/test'
make[1]: Entering directory `/.../icu-4.2/source'
verifying that icu-config --selfcheck can operate
verifying that make -f Makefile.inc selfcheck can operate
PASS: config selfcheck OK
make[1]: Leaving directory `/.../icu-4.2/source'
EDIT: réponses à des VolkerK Questions
J'ai installé ICU 4.2 de la source et comme je l'ai écrit au-dessus du processus de construction, les tests unitaires et l'installation tout est bien passé.
/usr/local/icu/bin/icu-config --version
4.2.0.1
/usr/local/icu/bin/icu-config --prefix
/usr/local/icu
/usr/local/icu/bin/icu-config --cppflags-searchpath
-I/usr/local/icu/include
/usr/local/icu/bin/icu-config --ldflags --ldflags-icuio
-lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio
objdump -C /usr/local/icu/lib/libicuuc.so.42.0.1
// doesn't work because of unrecognized argument -C
EDIT en ce qui concerne le commentaire de VolkerK:
Non, il n'y a pas de commutateur du compilateur impliqué - je courais à la fois construire des processus directement l'un après l'autre. Ne fonctionne pas objdump /usr/local/icu/lib/libicuuc.so.42.0.1 soit mais je réussi à exécuter
objdump -t /usr/local/icu/lib/libicuuc.so.42.0.1 | grep ubrk_close
00000000000d2484 g F .text 000000000000002d ubrk_close_4_2
Je ne sais pas si cette information peut aider.
Je pense qu'il ya le hic - il est en effet une autre version ICU sur le sytem; au moins dans les parties (il n'y a pas d'autre icu-config par exemple, que celui de /usr/local/icu/bin).
gcc -lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio -print-file-name=libicuuc.so rendements
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/libicuuc.so
alors que les rendements gcc -lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio -print-file-name=libicuuc.so.42
libicuuc.so.42
Le problème semble être, comment obtenir le nouveau chemin lib dans le processus de construction ?? Soit dit en passant, j'ai appris beaucoup de vos réponses - merci de vous tous
.J'ai aussi essayé de compiler votre programme de test simple - et il échoue aussi avec le même undefined reference erreur, très probablement en raison de la même raison PHP ne compilera pas.
Comment puis-je me débarrasser de la référence à l'ancienne bibliothèque ICU dans le chemin lib ou comment puis-je donner la priorité le nouveau chemin-ICU-bibliothèque?
La solution
Le problème semble être que le binaire est lié avec les fichiers de bibliothèque mal (partagé).
D'abord un long, ennuyeux de explaination ce que je pense que le problème est. Gardez à l'esprit que je ne suis pas un expert de Linux. Je veux vraiment que vous compreniez mon train de pensées afin que vous puissiez décider s'il est possible et / ou si je me trompe.
La première solution (brut) est facilement réversible. Exécutez un autre ./configure et tous les changements sont l'histoire. Je pense qu'il est assez sauver.
Pourquoi avez-vous ICU 4-2 dépendances spécifiques en premier lieu? Jetons un coup d'oeil à un fichier source de l'extension intl de php (ext / intl / graphème / grapheme_string.c)
#include <unicode/ubrk.h>
...
PHP_FUNCTION(grapheme_substr)
{
...
ubrk_close(bi);
...
Jusqu'à présent il n'y a pas de version code spécifique. grapheme_string.c a la même si vous utilisez ICU 3.4 ou 4.2 ICU. D'où vient le ubrk_close_4_2 vient?
Lorsque vous exécutez le "./configure ... --with-ICU-dir = / usr / local / ICU" commander le fichier ext / intl / config.m4 est exécuté. Dans ce processus ICU-config est appelé pour obtenir les fichiers à inclure de chemin et de bibliothèque nécessaires pour construire php. Vous avez fourni un chemin à votre installation de ICU qui se résume à cette
ICU_CONFIG="$PHP_ICU_DIR/bin/icu-config"
ICU_INCS=`$ICU_CONFIG --cppflags-searchpath`
ICU_LIBS=`$ICU_CONFIG --ldflags --ldflags-icuio`
est exécutée. Vous avez essayé ICU-config-vous, vous savez ce qu'il génère et donc ce ICU_INCS et ICU_LIBS contiennent.
ICU_INCS et ICU_LIBS sont passés à gcc lorsque les fichiers sont compilés / liés. gcc (Apperently) n'a pas trouvé unicode / ubrk.h dans son répertoire par défaut, il recherche le fichier dans le répertoire comprennent supplémentaires fournis par ICU_INCS où il a trouvé l'ICU 4.2 inclure des fichiers.
unicode / ubrk.h comprend unicode / utypes.h qui comprend alors unicode / urename.h - et encore les ICU 4.2 fichiers d'en-tête sont inclus. Dans ce cas unicode / urename.h #define comprend ubrk_close ubrk_close_4_2.
Lorsque le préprocesseur est fait ubrk_close (bi) a été remplacé par ubrk_close_4_2 (bi).
PHP_FUNCTION(grapheme_substr)
{
...
ubrk_close_4_2(bi);
...
Maintenant, vous avez une version spécifique de dépendance, une référence à ubrk_close_4_2 que certaines bibliothèque doit résoudre.
Ainsi, la partie a fait un travail comprennent. Il a en effet trouvé USI version 4.2 et a utilisé ses fichiers d'en-tête. Jusqu'à présent, si bon.
Maintenant, pour la partie de liaison. Dans votre cas ICU_LIBS contient
-lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio
-licuuc dit gcc « me trouver une bibliothèque appelée « icuuc » et de l'utiliser ». gcc recherche alors les chemins LIB pour les fichiers avec un certain schéma de nommage qui correspondent à « icuuc ».
Dans ce cas libicuuc.so. Notez qu'il ne cherche pas un nom de fichier spécifique de version, libicuuc.so. Une fois qu'il a trouvé un tel fichier, il ne regardera pas les uns des autres. recherche d'abord gcc dans ses chemins par défaut. Ensuite, il recherche les chemins de bibliothèque supplémentaires - dans l'ordre où ils sont fournis à gcc. I.e..
gcc -L / usr / lib -L / usr / local / lib -licuuc
trouvera /usr/lib/libicuuc.so s'il y a un tel fichier et non /usr/local/lib/libicuuc.so (plus). Ce qui signifie que soit le chemin par défaut ou l'ordre des directives de chemin bibliothèque peuvent être la cause de votre problème.
Lorsque votre programme est lié aux objets partagés un chargeur « spécial » est ajouté au code et le nom de l'objet partagé est stocké dans votre programme (au moment de la liaison).
Chaque fois que votre programme est exécuté, d'abord le chargeur (exécution) recherche l'objet partagé (par son nom), charge le code et remplace certaines adresses de saut de talon.
L'objet partagé peut « dire » l'éditeur de liens (par exemple au moment de la liaison) le nom de l'objet partagé le chargeur doit rechercher (propriété SONAME) lors de l'exécution.
Jetez un oeil à l'annuaire vous liste fournie dans le texte de votre question
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicuuc.so -> libicuuc.so.42.0.1
lrwxrwxrwx 1 root root 18 Jul 1 09:56 libicuuc.so.42 -> libicuuc.so.42.0.1
-rwxr-xr-x 1 root root 1660769 Jul 1 09:56 libicuuc.so.42.0.1
libicuuc.so, c'est le gcc de fichier est à la recherche quand -licuuc est fourni. L'éditeur de liens suit le lien symbolique et utilise libicuuc.so.42.0.1. Ce fichier « indique » l'éditeur de liens que le (exécution) chargeur doit rechercher libicuuc.so.42, voir http://userguide.icu-project.org/packaging#TOC-ICU-Versions .
Le chargeur suivra le libicuuc.so.42.0.1 symlink et la charge, ou s'il y a un autre bugfix libicuuc.so.42.0.2, libicuuc.so.42.0.3, quelle que soit libicuuc.so.42 pointe. libicuuc.so.42 va / doit toujours pointer vers un objet réel partagé qui exporte l'ICU 4.2 symboles. Le code peut être changé / fixe, mais les symboles exportés restent les mêmes.
Votre problème est maintenant que gcc ne trouve pas libicuuc.so-> libicuuc.so.42.0.1 mais (disons) libicuuc.so-> libicuuc.so.34.x.y. Cette libicuuc.so.34.x.y n'exporte pas l'ICU 4.2 symboles, il ne fournit pas ubrk_close_4_2 mais ubrk_close_3_4. Donc, pas ubrk_close_4_2 -.> Erreur de référence non résolue
Première "solution" (brut): Laissez-./configure sa magie puis ... il suffit d'éditer le Makefile
.
Ouvrez le Makefile (dans le répertoire racine source) dans un éditeur de texte, rechercher et remplacer INTL_SHARED_LIBADD =
-licui18n -licuuc -licudata -licuio
en ce que la ligne de
/usr/local/icu/lib/libicui18n.so.42 /usr/local/icu/lib/libicuuc.so.42 /usr/local/icu/lib/libicudata.so.42 / usr / local / ICU / lib / libicuio.so.42
(quitter tout -lm -pthread ... comme ils sont). Recompiler.
Ce « dit » le gcc / éditeur de liens de ne pas rechercher les fichiers .so mais d'utiliser ceux spécifiques. Le résultat devrait être le même que si votre chemin de la bibliothèque fonctionnait (beacuse de SONAME).
Mais chaque fois que vous exécutez ./configure vous devez appliquer le nouveau « fix ».
Deuxième solution: Supprimer les autres liens symboliques libicuXY.so (c'est là vient à l'esprit le mot « sauvegarde »), ne garder que les libicuXY.so-> libicuXY.so.42.0.1 liens. S'il n'y a pas d'autres libicuuc.so - >> libicuuc.so.34.x.y relie le gcc / éditeur de liens ne peut pas les trouver et ne se lier à la
anciennes versions.
Encore une fois à cause des binaires de propriété Soname qui ont déjà été liés avec l'ancienne version fonctionnera toujours parce que « leur » chargeur recherchera les fichiers libicuXY.so.34 (encore existants).
Cela affectera toutes les pistes de l'éditeur de liens suivants, à savoir si vous construisez un autre projet qui utilise le plus comprennent les fichiers que vous exécuterez dans le même problème dans l'autre sens. Les fichiers d'en-tête et les objets partagés (au moment de la liaison) doivent correspondre.
Autres conseils
Il y a une bonne chance que ld ne sait pas où trouver ces bibliothèques. Vous devrez soit LD_LIBRARY_PATH de mise à jour (à chaque fois), ou ont ldconfig apprendre de votre nouvelle bibliothèque.
Vous pouvez:
- Installez-le dans / usr / local / lib ou / usr / lib
- Ajouter son emplacement à /etc/ld.so.conf et re-run / sbin / ldconfig
En ce moment, même si ldconfig a été exécuté par tous installé la bibliothèque, ldconfig aurait aucune idée de son emplacement, car / usr / local / ICU / lib est pas dans son champ d'application. Si la bibliothèque a été installée dans / usr / local / lib / ICU, ldconfig saura où trouver, et vous ne devez spécifier le chemin LD manuellement.
Je recommande simplement réinstallant la bibliothèque / usr / ldconfig local / lib et en cours d'exécution avant de modifier ld.so.conf, toutefois modifier ce fichier est pas grand tabou si vous voulez juste pour le faire fonctionner.
Lorsque vous appelez
export LD_LIBRARY_PATH=/usr/local/icu/lib
vous écrasez le chemin actuellement défini. Ainsi, il pourrait être qu'il trouvera ICU, mais il ne trouvera aucune des autres bibliothèques dont il a besoin. Essayez ceci:
export LD_LIBRARY_PATH=/usr/local/icu/lib:${LD_LIBRARY_PATH}
Si cela ne vous aide pas, je peux penser à deux choses à essayer:
- La bibliothèque est au bon endroit? Peut-être que votre installation déplacé dans un autre endroit, comme à la place
/usr/local/lib/icu? - Est-ce que le travail de soins intensifs? Essayez la cible « make check » pour soins intensifs. Essayez de compiler / exécution de la suite de test inclus avec unité de soins intensifs, ou essayer de compiler et exécuter un exemple trivial unité de soins intensifs. Cette présentation (PPT) a quelques exemples triviaux.
EDIT
Je pense que je compris. Il ressemble à php-intl fonctionne uniquement avec libicu 3.6 ou 3.8. J'ai googlé pour toujours php-intl expédition distro Linux et ils tout dépend de libicu 3.8, même quand ils sont exportant également libicu 4.0 ou version ultérieure. dernière changelog avant intl est devenu une partie de PHP lui-même indique la même.
Je suggère d'installer libicu 3.8 et d'essayer à nouveau.
