I'm trying to build php-5.5.33 from source on a Debian 8 system; configure and make both run successfully, but when I run make install I get the following error:

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

Upon seeing this I ran (from dir /usr/src/www/php/php-5.5.33) ldd sapi/cli/php and saw the following (I've omitted most of the output):

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)

I was surprised to see this as I had used the --with-libxml-dir and --with-xsl options to specify the location of my locally installed, from source into /usr/local, version of libxml2-2.9.3 and libxslt-1.1.28. Also, configure seemed to have picked up this version because there were numerous instances in the output where it said:

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

Now, the make install error I listed above actually makes sense, as the symbol __xmlFree is not present in the system's /usr/lib/x86_64-linux-gnu/libxml2.so.2, as running readelf -s /usr/lib/x86_64-linux-gnu/libxml2.so | grep -i __xmlfree finds no matches. However, my locally installed version does contain this symbol:

$ 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

What is confusing is why sapi/cli/php is linking against a different version of libxml2 than what I have specified to configure. Note, my /etc/ld.so.conf is as follows:

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

...and that I have consolidated the /etc/ld.so.conf.d dir down to a single file that looks like this:

$ cat /etc/ld.so.conf.d/libs.conf

...and I have also run ldconfig after installing libxml2 and libxslt and prior to build php. Here is my full configure that I used:

./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 \

(Note also that, of all the items that were specified as /usr/local, php actually linked against the system versions of those too, if there were system versions available. Only items that had no system equivalents actually linked against the version I specified).

Why is php linking against different versions than what I have indicated? It seems that if this wasn't happening I probably wouldn't get the error during make install.


I have a very similar problem on Ubuntu 12 with php 5.5 & curl - I needed a newer curl, which I compiled and installed to /usr/local/curl-7.49.1.

Using --with-curl=/usr/local/curl-7.49.1 did not work as expected - the resulting binary was linked against /usr/lib/x86_64-linux-gnu/libcurl.so. BTW: My goal was to link curl statically to the php-binary with libcurl.a (to avoid version problems), but this was not the reason for the problems.

At this point I started to test my build with the enviroment variable LDFLAGS setting export LDFLAGS=-L/usr/local/curl-7.49.1/lib. This did also not work, same result as before.

After doing some research and tests (I am not a autoconf/Makefile specialist ;-) I noticed the call of libtool during the build process: libtool -L/usr/lib/x86_64-linux-gnu -L/usr/local/curl-7.49.1/lib [...]

The --with-libs parameter of the configure script is placed before the LDFLAGS Variable therefore libtool did not pick up my libcurl file but the one from the base system.

So I took a deeper look and tried to set EXTRA_LDFLAGS_PROGRAM instead of LDFLAGS:

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

Now the build succeeds. I do not know if this is the correct way to solve the problem nor if it´s a bug or a misconfiguration. I would be very happy if someone could clarify this to me.

So - your case isn't exactly the same, but give this a try before starting configure:

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

Let me know if this helps.


In case anyone is ever looking this up again, I am pretty sure the that the answer lies in the --libdir= parameter of the ./configure command:

  --libdir=DIR            object code libraries in DIR [EPREFIX/lib]

Sometimes you need --libdir=/usr/lib/x86_64-linux-gnu as Ubuntu keeps many libraries in /usr/lib/x86_64-linux-gnu and sometimes you need --libdir=/usr/local/lib such as when you have built libxml from source and placed it in /usr/local and in other cases, sometimes the simplest solution is to symlink the files from /usr/local/lib to /usr/lib/x86_64-linux-gnu

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.