Problemas de Compilación

Esta sección reúne la mayoría de los errores más comunes que ocurren al momento de compilar.

Tengo la última versión de PHP usando el servicio anónimo Git, pero no hay un script de configuración.

Se tiene que tener el paquete autoconf de GNU instalado y así se podrá generar el script de configuración desde configure.in. Solo se ejecuta ./buildconf en el directorio de nivel superior después de obtener los fuentes desde el servidor Git. (También, a menos que se ejecute configure con la opción --enable-maintainer-mode, el script de configuración no se recompilará automáticamente cuando el archivo configure.in es actualizado, así que debe asegurarse de hacerlo manualmente cuando se note que configure.in ha cambiado. Un síntoma de esto es encontrar cosas como @VARIABLE@ en el archivo Makefile después de configurar o ejecutar config.status).

Tengo problemas configurando PHP para que trabaje con Apache. Dice que no puede encontrar el httpd.h, ¡pero está justo donde digo que está!

Se necesita decirle al script configure/setup la ubicación del nivel superior del árbol de fuentes de Apache. Esto significa que se debe especificar --with-apache=/path/to/apache y no --with-apache=/path/to/apache/src.

Mientras se configura PHP (./configure), se devuelve un error similar al siguiente:

checking lex output file root... ./configure: lex: command not found
configure: error: cannot find output from lex; giving up

Se debe asegurar de leer cuidadosamente las instrucciones de instalación y notar que se necesita flex y bison instalados para compilar PHP. Dependiendo de la configuración, se necesitará instalar bison y flex desde las fuentes o desde un paquete, como un RPM.

Cuando intento iniciar Apache, obtengo el siguiente mensaje:

fatal: relocation error: file /path/to/libphp4.so:
symbol ap_block_alarms: referenced symbol not found

Este error usualmente se da cuando un programa del núcleo de Apache se compila como una biblioteca DSO para uso compartido. Se debe reconfigurar Apache, asegurándose de usar al menos los siguientes flags:

--enable-shared=max --enable-rule=SHARED_CORE

Para más información, leer el archivo de nivel superior de Apache INSTALL o las páginas del » manual sobre DSO.

Cuando ejecuto la configuración, dice que no puede encontrar los archivos o bibliotecas para GD, gdbm, o algún otro paquete.

Se puede configurar el script para que busque los archivos de encabezados y bibliotecas en ubicaciones no estándar especificando flags adicionales para ser pasados al preprocesador y compilador C, como:

    CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure

Si se está usando una variante de csh como login shell (¿por qué?), debería ser:

    env CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure

Cuando se está compilando el archivo language-parser.tab.c, da errores así yytname undeclared.

Se debe actualizar la versión de Bison. Se puede encontrar la última versión en » http://www.gnu.org/software/bison/bison.html.

Cuando ejecuto make, parece que se ejecuta bien, pero luego falla cuando intenta enlazar la aplicación final quejándose de que faltan algunos archivos.

Algunas versiones antiguas de make no colocan correctamente las versiones compiladas de los archivos del directorio functions en ese mismo directorio. Se debe intentar ejecutar cp *.o functions y entonces volver a ejecutar make para ver si eso ayuda. Si lo hace, realmente se debería actualizar a una versión reciente de GNU make.

Cuando se enlaza PHP, se queja de varias referencias indefinidas.

Hay que mirar la línea del enlace y asegurarse de que todas las bibliotecas apropiadas han sido incluidas al final. Las más comunes que podrían haberse olvidado son '-ldl' y las bibliotecas requeridas como soporte por cualquier base de datos que se haya incluido.

Algunas personas han reportado que han tenido que adicionar '-ldl' inmediatamente seguido por libphp4.a cuando enlazan con Apache.

He seguido todos los pasos para instalar la versión del módulo de Apache en Unix, y mis scripts de PHP se muestran en el navegador o se me pide guardar el archivo.

Esto significa que el módulo de PHP no está siendo invocado por alguna razón. Hay tres cosas que chequear antes de pedir ayuda:

• Asegurarse de que el binario del httpd que se está ejecutando es el nuevo binario httpd que se acaba de hacer. Para ver esto, se debe intentar ejecutar: /path/to/binary/httpd -l

  Si no se ve mod_php4.c listado, entonces no se está ejecutando el binario correcto. Hay que encontrarlo e instalar el binario correcto.

• Asegurarse de que se ha agregado el tipo MIME correcto en uno de los archivos de Apache .conf. Debería de ser: AddType application/x-httpd-php .php

  También asegurarse de que esta línea AddType no está oculta dentro de un bloque <VirtualHost> o <Directory> el cual podría evitar que se aplique en el lugar donde se prueba el script.

• Por último, el lugar por defecto de los archivos de configuración de Apache cambió entre Apache 1.2 y Apache 1.3. Se debería comprobar que el archivo de configuración al cual se le agrega la línea AddType está siendo leído realmente. Se puede poner un error de sintaxis obvio dentro del archivo httpd.conf o algún otro cambio que pueda decir si el archivo está siendo leído de forma correcta.

Dice que use: --activate-module=src/modules/php4/libphp4.a, pero ese archivo no existe, así que lo cambié a --activate-module=src/modules/php4/libmodphp4.a y no funciona. ¿Qué está pasando?

Hay que tener en cuenta que el archivo libphp4.a no se supone que exista. ¡El proceso de Apache lo creará!

Cuando intento compilar Apache con PHP como un módulo estático usando --activate-module=src/modules/php4/libphp4.a me dice que mi compilador no es compatible con ANSI.

Este es un mensaje de error equivocado de Apache que ha sido corregido en las versiones más recientes.

Cuando intento compilar PHP usando --with-apxs obtengo mensajes de error extraños.

Hay tres cosas que comprobar aquí. Primero, por alguna razón cuando Apache compila el script de Perl apxs, algunas veces termina compilandose sin el compilador apropiado y sin los flags correspondientes. Hay que encontrar el script apxs (intentar con el comando which apxs), algunas veces se encuentra en /usr/local/apache/bin/apxs o /usr/sbin/apxs. Abrirlo y revisar las líneas similares a estas:

my $CFG_CFLAGS_SHLIB  = ' ';          # substituted via Makefile.tmpl
my $CFG_LD_SHLIB      = ' ';          # substituted via Makefile.tmpl
my $CFG_LDFLAGS_SHLIB = ' ';          # substituted via Makefile.tmpl

Si esto es lo que se ve, se ha encontrado el problema. Podrían contener espacios u otros valores incorrectos, como 'q()'. Hay que cambiar esas líneas para que digan:

my $CFG_CFLAGS_SHLIB  = '-fpic -DSHARED_MODULE'; # substituted via Makefile.tmpl
my $CFG_LD_SHLIB      = 'gcc';                   # substituted via Makefile.tmpl
my $CFG_LDFLAGS_SHLIB = q(-shared);              # substituted via Makefile.tmpl

El segundo problema posible podría ser un caso único en Red Hat 6.1 y 6.2. El script apxs de Red Hat está defectuoso. Hay que ver esta línea:

my $CFG_LIBEXECDIR    = 'modules';         # substituted via APACI install

Si se ve como la línea anterior, hay que cambiarla por:

my $CFG_LIBEXECDIR    = '/usr/lib/apache'; # substituted via APACI install

Por último, si se reconfigura/reinstala Apache, hay que agregar un make clean al proceso después de ./configure y antes de make.

Durante el make, obtengo errores sobre microtime, y muchas cosas de RUSAGE_.

Durante la parte de la instalación de make, si se encuentran problemas que se vean similares a esto:

microtime.c: In function `php_if_getrusage':
microtime.c:94: storage size of `usg' isn't known
microtime.c:97: `RUSAGE_SELF' undeclared (first use in this function)
microtime.c:97: (Each undeclared identifier is reported only once
microtime.c:97: for each function it appears in.)
microtime.c:103: `RUSAGE_CHILDREN' undeclared (first use in this function)
make[3]: *** [microtime.lo] Error 1
make[3]: Leaving directory `/home/master/php-4.0.1/ext/standard'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/master/php-4.0.1/ext/standard'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/master/php-4.0.1/ext'
make: *** [all-recursive] Error 1

Significa que el sistema esta mal. Se necesita corregir los archivos /usr/include instalando el paquete glibc-devel que coincida con su glibc. Esto no tiene nada que ver con PHP. Para comprobar esto, hay que hacer esta simple prueba:

$ cat >test.c <<X
#include <sys/resource.h>
X
$ gcc -E test.c >/dev/null

Si esto produce errores, se sabrá que los archivos incluidos están mal.

Cuando compilo PHP con MySQL, la configuración se ejecuta bien, pero durante el make obtengo un error similar al siguiente: ext/mysql/libmysqlclient/my_tempnam.o(.text+0x46): In function my_tempnam': /php4/ext/mysql/libmysqlclient/my_tempnam.c:103: the use of tempnam' is dangerous, better use mkstemp', ¿Qué está mal?

Primero, es importante darse cuenta que esto es un Warning y no un error fatal. Debido a que esto es la última salida vista durante el make, podría verse como un error fatal pero no lo es. Por supuesto, si se ha puesto el compilador a que pare en los Warnings, lo hará. También hay que tener en mente que el soporte por MySQL es habilitado por defecto.

Nota:

A partir de PHP 4.3.2, se verá el siguiente texto después de que se complete la compilación (make):

Compilación completada.
(Es seguro hacer caso omiso de las advertencias sobre tempnam y tmpnam).

Deseo actualizar mi PHP. ¿Dónde puedo encontrar la línea ./configure que fue usada para compilar mi instalación actual de PHP?

Si se mira el archivo config.nice, en el árbol origen de la instalación actual de PHP o, si esto no está disponible, simplemente se debe ejecutar un script con

<?php phpinfo(); ?>

Al inicio de la salida se mostrará la línea ./configure que fue usada para compilar la instalación de PHP.

Cuando compilo PHP con la biblioteca GD, también da errores raros de compilación o segfaults en la ejecución.

Hay que asegurarse de que la biblioteca GD y PHP están enlazados contra las mismas bibliotecas dependientes (ej: libpng).

Cuando compilo PHP parece que recibo errores al azar, como si se colgara. Estoy usando Solaris si eso importa.

Usando utilidades no-GNU mientras se compila PHP podría causar problemas. Hay que asegurarse de usar herramientas GNU para estar seguros que la compilación de PHP funcionará. Por ejemplo, en Solaris, usando el SunOS BSD-compatible o versiones de Solaris de sed no funcionará, pero usando las versiones GNU o Sun POSIX (xpg4) de sed hará que funcione. Enlaces: » GNU sed, » GNU flex, y » GNU bison.