Mdthbs

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

/usr/local/lib

/usr/lib/x86_64-linux-gnu/libfakeroot

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

--without-pdo-sqlite

(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