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.

2 Answers 2


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .