Problemas con la instalación de PHP 5.3.0 con intl-apoyo
https://stackoverflow.com/questions/1078412
-
21-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Actualmente estoy tratando de instalar PHP 5.3.0 en algunos Linux en el servidor de prueba.Como hemos urgencia esperó ext/intl queremos echa un vistazo a las características que ofrece.Estoy corriendo configure con éxito con los siguientes argumentos
./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
La UCI 4.2 está situado en la /usr/local/icu y PHP 5.2.9 compilado sin problemas (sin int - y uci-opciones).Pero cuando me complie el PHP 5.3.0 fuente tengo un montón de mensajes de error del tipo
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'
Estoy bastante seguro de que tiene algo que ver con no encontrar las librerías compartidas.Configuración
export LD_LIBRARY_PATH=/usr/local/icu/lib
no ayuda.
Puede alguien me apunte a alguna solución?Soy bastante despistado - y yo no soy un verdadero experto en estas cosas...
EDITAR:
Acabo de volver a revisar y asegurarse de que las distintas uci-las bibliotecas y los respectivos enlaces simbólicos se encuentran en /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 corre toneladas de pruebas - todos ellos con éxito:
[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'
EDITAR:respuestas a VolkerK del preguntas
He instalado la UCI 4.2 de la fuente y como escribí anteriormente el proceso de generación, la unidad de pruebas de la instalación y todo salió bien.
/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
EDITAR con respecto a VolkerK comentario:
No, no ha habido ningún modificador de compilador involucrados - corrí a construir procesos directamente una después de la otra. objdump /usr/local/icu/lib/libicuuc.so.42.0.1 no funciona bien, pero me las arreglé para ejecutar
objdump -t /usr/local/icu/lib/libicuuc.so.42.0.1 | grep ubrk_close
00000000000d2484 g F .text 000000000000002d ubrk_close_4_2
No sé si esta información le puede ayudar.
EDICIÓN en VolkerK del edit1 y edit2:
Creo que ahí está el problema - de hecho hay otro uci-versión en el sistema;al menos en algunas partes (no hay otra uci-config, por ejemplo;sólo el uno en /usr/local/icu/bin).
gcc -lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio -print-file-name=libicuuc.so devuelve
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/libicuuc.so
mientras gcc -lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio -print-file-name=libicuuc.so.42 devuelve
libicuuc.so.42
Así que el problema parece ser, cómo obtener la nueva lib-ruta de acceso en el proceso de construcción??Por el camino, he aprendido mucho de sus respuestas, gracias a todos ustedes.
También traté de compilar su programa de prueba sencillo - y también se produce el mismo referencia indefinida error, lo más probable debido a la misma razón de PHP no se compilará.
¿Cómo puedo deshacerme de la referencia a la antigua uci-biblioteca en el directorio lib de la ruta o ¿cómo priorizar la nueva uci-library-path?
Solución
El problema parece ser que el binario está vinculado contra el mal (compartido) los archivos de la biblioteca.
Primera de una larga, aburrida explicación de lo que creo que es el problema.Tenga en cuenta que yo no soy un linux experto.Realmente quiero que usted entienda mi tren de pensamientos de modo que usted puede decidir si es factible y/o en que estoy mal.
La primera (de crudo) la solución es fácilmente reversible.Ejecutar otra ./configurar y todos los cambios son historia.Creo que es bastante guardar.
¿Por qué la uci 4-2 dependencias específicas en el primer lugar?Echemos un vistazo a un archivo de código fuente de php intl extensión (ext/intl/grafema/grapheme_string.c)
#include <unicode/ubrk.h>
...
PHP_FUNCTION(grapheme_substr)
{
...
ubrk_close(bi);
...
Hasta ahora no hay una versión de código específico.grapheme_string.c ve el mismo si se utilizan uci 3.4 o uci 4.2.¿De dónde viene el ubrk_close_4_2 vienen?
Al ejecutar "./configurar ...--with-uci-dir=/usr/local/uci" comando el archivo ext/intl/config.m4 es ejecutado.En este proceso de uci-config se llama para obtener la ruta de biblioteca y archivos necesarios para compilar php.Se proporciona una ruta de acceso a la uci de la instalación que se reduce a que
ICU_CONFIG="$PHP_ICU_DIR/bin/icu-config"
ICU_INCS=`$ICU_CONFIG --cppflags-searchpath`
ICU_LIBS=`$ICU_CONFIG --ldflags --ldflags-icuio`
se ejecuta.Has probado la uci de configuración de ti mismo, entonces usted sabe lo que los resultados y por lo tanto lo que ICU_INCS y ICU_LIBS contienen.ICU_INCS y ICU_LIBS se pasan a gcc cuando los archivos se compilan/vinculadas.gcc (el apperently) no encuentra unicode/ubrk.h en el directorio por defecto, así que busqué el archivo en los directorios de inclusión adicionales proporcionados por ICU_INCS donde se encuentra la unidad de cuidados intensivos 4.2 incluir archivos.unicode/ubrk.h incluye unicode/utypes.h y que, a continuación, incluye unicode/urename.h - y de nuevo la uci 4.2 se incluya archivos de encabezado.En este caso unicode/urename.h incluye #define ubrk_close ubrk_close_4_2.
Cuando el preprocesador se hace ubrk_close(bi) ha sido sustituido por ubrk_close_4_2(bi).
PHP_FUNCTION(grapheme_substr)
{
...
ubrk_close_4_2(bi);
...
Ahora usted tiene una versión específica de dependencia, una referencia a ubrk_close_4_2 que algunos de la biblioteca tiene que resolver.
Así que el incluir parte hizo el trabajo.De hecho encontrar tu uci versión 4.2 y utilizar sus archivos de encabezado.Hasta ahora tan bueno.
Ahora para el vinculador parte.En su caso ICU_LIBS contiene
-lpthread -lm -L/usr/local/icu/lib -licui18n -licuuc -licudata -lpthread -lm -licuio
-licuuc indica a gcc "me encontrarán una biblioteca llamada 'icuuc' y la utilizan".el gcc, busca en el LIB rutas de acceso para archivos con un cierto esquema de nombres que coinciden con "icuuc".
En este caso libicuuc.así.Tenga en cuenta que no busca una versión específica de nombre de archivo, sólo libicuuc.así.Una vez que ha encontrado un archivo no mirar para otro.Primera gcc búsquedas en sus rutas de acceso predeterminadas.A continuación, busca en la biblioteca adicionales caminos - en el orden indicado para gcc.I. e.
gcc-L/usr/lib -L/usr/local/lib -licuuc
se encuentra en /usr/lib/libicuuc.así que si hay un archivo de este tipo y no en /usr/local/lib/libicuuc.así que (ya).Lo que significa que la ruta de acceso predeterminada o el orden de la ruta de biblioteca directrices pueden ser la causa de sus problemas.
Cuando se vincula el programa contra objetos compartidos "especial" cargador se agrega el código y el nombre de los objetos compartidos se almacenan en su programa (en tiempo de vínculo).
Cada vez que se ejecuta un programa, primero el (tiempo de ejecución) gestor de búsquedas para el objeto compartido (por su nombre), carga el código y reemplaza algunas punta de saltar direcciones.
El objeto compartido puede "decirle" al enlazador (es decir,en el momento de enlazar) el nombre del objeto compartido el cargador debe buscar (SONAME de propiedad) en tiempo de ejecución.Echa un vistazo a la lista de directorios que usted proporcionó en el texto de su pregunta
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.así que, ese es el archivo gcc está buscando cuando -licuuc se proporciona.El vinculador sigue el enlace y utiliza libicuuc.así.42.0.1.Este archivo "dice" el enlazador que el (tiempo de ejecución) cargador debe buscar libicuuc.así.42, ver http://userguide.icu-project.org/packaging#TOC-ICU-Versions.
El cargador se siga el enlace y carga libicuuc.así.42.0.1, o si hay otra corrección de errores libicuuc.así.42.0.2, libicuuc.así.42.0.3, lo que libicuuc.así.42 señala.libicuuc.así.42/siempre debe apuntar a un objeto compartido en el que las exportaciones de la uci 4.2 símbolos.El código puede haber cambiado/fijo, pero los símbolos exportados estancia en el mismo.El problema ahora es que gcc no encontrar libicuuc.por lo que->libicuuc.así.42.0.1 pero (vamos a decir) libicuuc.por lo que->libicuuc.así.34.x.y.Este libicuuc.así.34.x.y no exportar la uci 4.2 símbolos, no ofrece ubrk_close_4_2 pero ubrk_close_3_4.Así que, no ubrk_close_4_2 -> no resueltos de error de referencia.
Primera "solución" (crudo):Vamos ./configurar haga su magia y, a continuación, ...basta con editar el fichero Makefile.
Abra el archivo Makefile (en la fuente directorio superior) en un editor de texto, búsqueda de INTL_SHARED_LIBADD= y reemplazar
-licui18n -licuuc -licudata -licuio
en esa línea por
/usr/local/uci/lib/libicui18n.así.42 /usr/local/uci/lib/libicuuc.así.42 /usr/local/uci/lib/libicudata.así.42 /usr/local/uci/lib/libicuio.así.42
(salir de cualquier -lm -pthread ...como son).Vuelva a compilar.
Esta "le dice a" el gcc/enlazador no para buscar la .por lo que los archivos pero el uso de los específicos.El resultado debe ser el mismo como si su ruta de biblioteca estaba trabajando (porque de SONAME).
Pero cada vez que se ejecute ./configurar tienes que aplicar el "fix" de nuevo.
Segunda solución:Quitar el otro libicuXY.así que los enlaces simbólicos (que es donde la palabra "copia de seguridad" viene a la mente), sólo para mantener la libicuXY.por lo que->libicuXY.así.42.0.1 enlaces.Si no hay ningún otro libicuuc.así>>libicuuc.así.34.x.y los enlaces de la gcc/enlazador no puede encontrar y no vinculará en contra de las versiones antiguas.
De nuevo, por el SONAME propiedad binarios que ya se han vinculado en contra de la versión antigua seguirá funcionando porque "su" cargador de búsqueda para el (todavía existente) libicuXY.así.34 archivos.
Esto afectará a todas las posteriores enlazador se ejecuta, es decir,si usted construir otro proyecto que utiliza los mayores incluir archivos que se ejecutará en el mismo problema al revés.Los archivos de encabezado y los objetos compartidos (en el momento de enlazar) deben coincidir.
Otros consejos
Hay una buena probabilidad de que ld no sabe dónde encontrar esas bibliotecas.Usted tendrá que actualizar LD_LIBRARY_PATH (cada vez), o ldconfig aprender de su nueva biblioteca.
Usted puede:
- Instalarlo en /usr/local/lib o /usr/lib
- Agregar su ubicación a /etc/ld.así.conf y volver a ejecutar el comando /sbin/ldconfig
Ahora, incluso si ldconfig se ejecute, por cualquier instalada la biblioteca, ldconfig no tiene idea de su ubicación debido a que /usr/local/uci/lib no está en su ámbito de aplicación.Si la biblioteca se ha instalado en /usr/local/lib/uci, ldconfig sabría dónde encontrarla, y usted no tiene que especificar el LD ruta manualmente.
Te recomiendo volver a instalar la biblioteca /usr/local/lib y ejecutar ldconfig antes de la modificación de la ld.así.conf, sin embargo modificar ese archivo no es un gran tabú si usted sólo desea que funcione.
Cuando llame
export LD_LIBRARY_PATH=/usr/local/icu/lib
a continuación, va a sobrescribir la actualidad la ruta.Así que podría ser que se va a encontrar la UCI, pero no encontrará ninguna de las otras bibliotecas que necesita.Pruebe esto en su lugar:
export LD_LIBRARY_PATH=/usr/local/icu/lib:${LD_LIBRARY_PATH}
Si eso no ayuda, no puedo pensar en dos cosas para probar:
- Es la biblioteca en el lugar correcto?Tal vez su instalación movido en algún otro lugar, como
/usr/local/lib/icuen su lugar? - ¿UCI trabajo?Pruebe el "cheque" de destino para la UCI.Tratar de compilar/ejecutar el conjunto de pruebas se incluye con la UCI, o intenta compilar y ejecutar un trivial UCI ejemplo. Esta presentación (PPT) tiene un par de ejemplos triviales.
EDITAR
Creo que lo he descubierto.Parece php-intl sólo funciona con libicu 3.6 o 3.8.He buscado en google para siempre distro de Linux envío php-intl y que todo depende de libicu 3.8 incluso cuando son también envío libicu 4.0 o posterior.El el último changelog antes intl se convirtió en parte de php en sí indica el mismo.
Sugiero instalar libicu 3.8 y volver a intentarlo.
