php liga-se ao sistema libxml em vez da versão especificada por ./configure --with-libxml-dir

Question

Estou tentando construir o php-5.5.33 a partir do código-fonte em um sistema Debian 8; configure e make ambos são executados com sucesso, mas quando executo make install , recebo o seguinte erro:

Installing PEAR environment:      /usr/local/lib/php/
/usr/src/www/php/php-5.5.33/sapi/cli/php: symbol lookup error:     /usr/src/www/php/php-5.5.33/sapi/cli/php: undefined symbol: __xmlFree
Makefile:390: recipe for target 'install-pear-installer' failed
make[1]: *** [install-pear-installer] Error 127
Makefile:393: recipe for target 'install-pear' failed
make: *** [install-pear] Error 2

Ao ver isso eu corri (de dir /usr/src/www/php/php-5.5.33 ) ldd sapi/cli/php e vi o seguinte (eu omiti a maior parte da saída):

libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x00007efd9c207000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007efd9bea0000)

Fiquei surpreso ao ver isso, pois usei as opções --with-libxml-dir e --with-xsl para especificar o local do meu instalado localmente, da origem para a versão / usr / local, de libxml2-2.9.3 e libxslt-1.1 28. Além disso, o configure parecia ter escolhido essa versão porque havia várias instâncias na saída em que ela dizia:

checking for xml2-config path... /usr/local/bin/xml2-config
checking whether libxml build works... yes

Agora, o erro make install que listei acima realmente faz sentido, pois o símbolo __xmlFree não está presente no /usr/lib/x86_64-linux-gnu/libxml2.so.2 do sistema, pois a execução readelf -s /usr/lib/x86_64-linux-gnu/libxml2.so | grep -i __xmlfree não encontrou correspondências. No entanto, minha versão instalada localmente contém este símbolo:

$ readelf -s /usr/local/lib/libxml2.so.2 | grep -i __xmlfree
1409: 00000000000e0b5c    35 FUNC    GLOBAL DEFAULT   12 __xmlFree
5249: 00000000000e0b5c    35 FUNC    GLOBAL DEFAULT   12 __xmlFree

O que é confuso é porque o sapi/cli/php está vinculado a uma versão diferente do libxml2 do que o que eu especifiquei para configure . Observe que meu /etc/ld.so.conf é o seguinte:

$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

... e que eu consolidei o /etc/ld.so.conf.d dir para um único arquivo que se parece com isso:

$ cat /etc/ld.so.conf.d/libs.conf
/usr/local/lib
/usr/lib/x86_64-linux-gnu/libfakeroot

... e também corri ldconfig depois de instalar libxml2 e libxslt e antes de compilar o php. Aqui está o meu configure completo que usei:

./configure --prefix=/usr/local \
CFLAGS="-O2 -mtune=native -funroll-loops -fPIC" \
--with-libdir=lib \
--with-apxs2=/usr/local/apache2/bin/apxs \
--disable-debug \
--disable-short-tags \
--enable-libgcc \
--enable-shared=yes \
--enable-calendar \
--enable-exif \
--enable-ftp \
--enable-gd-native-ttf \
--enable-mbstring \
--enable-shmop \
--enable-soap \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--with-bz2 \
--with-curl=/usr/local \
--with-freetype-dir \
--with-gd \
--with-gnu-ld \
--with-iconv-dir=/usr/local \
--with-jpeg-dir=/usr/local \
--with-ldap=/usr/local \
--with-libxml-dir=/usr/local \
--with-mcrypt \
--with-mhash \
--with-openssl \
--with-openssl-dir=/usr/local \
--with-pear \
--with-pcre-regex=/usr/local \
--with-pcre-dir=/usr/local \
--with-png-dir=/usr/local \
--with-tidy \
--with-readline \
--with-tsrm-pthreads \
--with-xmlrpc \
--with-xsl=/usr/local \
--with-zlib \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--without-sqlite3 \
--without-pdo-sqlite

(Note também que, de todos os itens que foram especificados como / usr / local, o php realmente se ligava às versões do sistema deles também, se houvesse versões do sistema disponíveis. Somente itens que não possuíssem equivalentes do sistema realmente vinculados ao versão especificada).

Por que o php é vinculado a versões diferentes das que eu indiquei? Parece que, se isso não estivesse acontecendo, provavelmente não receberia o erro durante make install .

    

Answer 1

Eu tenho um problema muito semelhante no Ubuntu 12 com php 5.5 & curl - Eu precisava de um novo curl, que eu compilei e instalei em /usr/local/curl-7.49.1 .

O uso de --with-curl=/usr/local/curl-7.49.1 não funcionou como esperado - o binário resultante foi vinculado a /usr/lib/x86_64-linux-gnu/libcurl.so . BTW: Meu objetivo era vincular estaticamente o curl ao php-binário com libcurl.a (para evitar problemas de versão), mas essa não era a razão para os problemas.

Neste ponto, comecei a testar minha compilação com a variável de ambiente LDFLAGS setting export LDFLAGS=-L/usr/local/curl-7.49.1/lib . Isso também não funcionou, o mesmo resultado de antes.

Depois de fazer algumas pesquisas e testes (eu não sou um especialista em autoconf / Makefile ;-) eu notei a chamada da libtool durante o processo de construção: libtool -L/usr/lib/x86_64-linux-gnu -L/usr/local/curl-7.49.1/lib [...]

O parâmetro --with-libs do script de configuração é colocado antes da variável LDFLAGS , portanto a libtool não selecionou meu arquivo libcurl, mas aquele do sistema básico.

Então, eu dei uma olhada mais profunda e tentei definir EXTRA_LDFLAGS_PROGRAM em vez de LDFLAGS :

export EXTRA_LDFLAGS_PROGRAM=-L/usr/local/curl-7.49.1/lib

Agora a compilação é bem-sucedida. Não sei se esta é a maneira correta de resolver o problema nem se é um bug ou uma configuração incorreta. Eu ficaria muito feliz se alguém pudesse esclarecer isso para mim.

Então - o seu caso não é exatamente o mesmo, mas experimente antes de iniciar o configure:

export EXTRA_LDFLAGS_PROGRAM=-L/usr/local/lib/

Deixe-me saber se isso ajuda.