ID: 44087
Updated by: [EMAIL PROTECTED]
Reported By: hz at nyphp dot com
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: CentOS 4.5 x86_64
PHP Version: 5.2.5
New Comment:
You're trying to do something we don't support. Not PHP bug -> bogus.
Previous Comments:
------------------------------------------------------------------------
[2008-02-14 23:01:10] 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-14 22:50:58] [EMAIL PROTECTED]
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 ld.so.conf 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 02:17:46] hz at nyphp dot com
I think this is already done:
[EMAIL PROTECTED] etc]# ldconfig -p | grep -i xml
libxml2.so.2 (libc6,x86-64) => /usr/local/lib/libxml2.so.2
libxml2.so.2 (libc6,x86-64) => /usr/lib64/libxml2.so.2
libxml2.so (libc6,x86-64) => /usr/local/lib/libxml2.so
libxml2.so (libc6,x86-64) => /usr/lib64/libxml2.so
libxmlsec1.so.1 (libc6,x86-64) => /usr/lib64/libxmlsec1.so.1
libxmlsec1.so (libc6,x86-64) => /usr/lib64/libxmlsec1.so
libxmlsec1-openssl.so.1 (libc6,x86-64) =>
/usr/lib64/libxmlsec1-openssl.so.1
libxmlsec1-openssl.so (libc6,x86-64) =>
/usr/lib64/libxmlsec1-openssl.so
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-13 17:05:26] [EMAIL PROTECTED]
You need to set the library paths correctly in /etc/ld.so.conf and make
sure the path to the new libxml2 libraries is above any other like
/usr/lib64
------------------------------------------------------------------------
[2008-02-09 18:19:35] hz at nyphp dot com
Description:
------------
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 \
--with-libxml-dir=/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 libphp5.la
grep: /usr/lib64/libxml2.la: No such file or directory
/bin/sed: can't read /usr/lib64/libxml2.la: No such file or directory
libtool: link: `/usr/lib64/libxml2.la' is not a valid libtool archive
make: *** [libphp5.la] 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.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=44087&edit=1
