|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44087 Not using correct libxml
Submitted: 2008-02-09 18:19 UTC Modified: 2008-02-28 12:54 UTC
From: hz at nyphp dot com Assigned:
Status: Not a bug Package: Compile Failure
PHP Version: 5.2.5 OS: CentOS 4.5 x86_64
Private report: No CVE-ID: None
 [2008-02-09 18:19 UTC] hz at nyphp dot com
CentOS 4.5 comes with an older version of libxml2, so I've compiled my own version and installed to /usr/local

Then I configure PHP using:

./configure \
--with-libdir=lib64 \
--prefix=/usr/local/php \
--with-apxs=/usr/local/apache/bin/apxs \
--with-openssl \
--with-zlib \
--with-curl \
--with-mysql=/usr \
--with-mysqli=/usr/bin/mysql_config \
--disable-pdo \
--without-sqlite \
--enable-pcntl \
--with-xsl=/usr/local \

make fails with errors as in bug #39940.

When I move /usr/lib64/libxml2* to a temporary directory (and rerun ldconfig), I get the following error during make:

-lxml2 -lz -lm -lcrypt  -o
grep: /usr/lib64/ No such file or directory
/bin/sed: can't read /usr/lib64/ No such file or directory
libtool: link: `/usr/lib64/' is not a valid libtool archive
make: *** [] Error 1

So obviously PHP is not completely listening to where I told it to find libxml2.  However, during ./configure, it indicates /usr/local/bin/xml2-config is being used.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-13 17:05 UTC]
You need to set the library paths correctly in /etc/ and make sure the path to the new libxml2 libraries is above any other like /usr/lib64

 [2008-02-14 02:17 UTC] hz at nyphp dot com
I think this is already done:

[root@xxx etc]# ldconfig -p | grep -i xml (libc6,x86-64) => /usr/local/lib/ (libc6,x86-64) => /usr/lib64/ (libc6,x86-64) => /usr/local/lib/ (libc6,x86-64) => /usr/lib64/ (libc6,x86-64) => /usr/lib64/ (libc6,x86-64) => /usr/lib64/ (libc6,x86-64) => /usr/lib64/ (libc6,x86-64) => /usr/lib64/

And regardless, shouldn't specifying the directory prefix with --with-libxml-dir=/usr/local and then thus it locating the correct /usr/local/bin/xml2-config during ./configure override the ordering in ldconfig irrelevant?
 [2008-02-14 22:50 UTC]
First of all, it's still not finding the correct 64bit libraries.
And 2nd issue is that xml2-config doesn't even have any paths in it for libraries, at least not the version I have:

# xml2-config --libs
-lxml2 -lz -lm

So it's all up to the to decide the correct order.
Anyway, the main problem here is that your system has two conflicting sets of libraries installed, you should run configure and 'make' when those older ones are NOT in there..
 [2008-02-14 23:01 UTC] hz at nyphp dot com
It's quite common to have multiple versions of the same library installed in different places.  That's exactly why the various *-dir options exist in ./configure - so that you can specify which library to use.

The ordering of ldconfig is correct, so this is not the problem.  And in fact, ./configure is trying to find the right library, by indicating that it's looking at the /usr/local/bin/xml2-config, but then somewhere it's hardwired to look at /usr/lib or /usr/lib64

As my original report mentioned, this version of CentOS requires that older version of libxml, so waiting until "those older ones are NOT in there" isn't even realistic.

Why is ./configure looking for libraries outside of where I've specifically pointed it to?  This is the problem, nothing more.
 [2008-02-24 19:41 UTC]
You're trying to do something we don't support. Not PHP bug -> bogus.
 [2008-02-24 19:47 UTC] hz at nyphp dot com
PHP doesn't support --with-libxml-dir=/usr/local to specify where to find libxml?  Then it should be taken out of ./configure --help

Can someone else look at this?
 [2008-02-28 12:54 UTC]
Unless you also rebuilt libxslt against the newly build libxml2, the xsl 
config will override the libxml2 config and cause php to be linked to 
the older libxml2. Try removing --with-xsl and see if it starts linking 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon May 16 11:05:45 2022 UTC