The root of your problem is that ext/domxml/config.m4 looks for libxml2 specifically in $DOMXML_DIR/lib
And if it doesn't find it there, then it defaults to using -lxml instead of -lxml2. Now where this breaks for you is that libxml doesn't exist, but libxml2 does. If you look at that config.m4 file, you will see tests around line 54 that are hardcoded to $DOMXML_DIR/lib Again, if you look at the Suse php config patch it will show you what you need to change to get it up and running. http://www.bobsilva.com/php-4.3.3-lib64.diff It's a big patch, but it does resolve the issues with php on a 64bit SuSE platform. Unfortunately the patch is for 4.3.3 so it is unlikely to work if applied to > 4.3.3 Bob -----Original Message----- From: Hans Zaunere [mailto:[EMAIL PROTECTED] Sent: Saturday, September 25, 2004 12:31 PM To: James Devenish Cc: [EMAIL PROTECTED] Subject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64 > > However, there is one issue I'm pretty unclear on - and, unfortunately > > it might relate to some of the other issues, which makes matters more > > confusion. > [...] > > -- In general, I've found that PHP's ./configure tends to assume things > > are in /usr/lib. However, on this and other 64bit x86 platforms, what > > we want is typically in /usr/lib64. A prime example of this is libjpeg. > [...] > > configure: error: libjpeg.(a|so) not found. > [...] > > The solution: symlink libjpeg.so from /usr/lib64 into /usr/lib - but is > > this right? I've tried numerous flags to configure, but nothing worked. > > When examining config.log in this case, I see "gcc -o conftest > > -L/usr/lib64...." which looks to be on the right track, yet ./configure > > is still breaking. > > Yes, the PHP4 ./configure internals have been broken in this way for a > number of years and bug reports have been filed accordingly. As you have > noted, the compiler has no difficulty finding the libs but the configure > script itself fails while performing its own (spurious) path search. > This is an artificial failure and cannot be corrected with command-line > options in the version you are using (4.3.8, by the looks of it). If > this is the problem you are experiencing, then all you need to do is > hack ./configure so that it ignores these "errors". For example, if > ./configure fails on this: > > { echo "configure: error: libjpeg.(a|so) not found." 1>&2; exit 1; } > > then you can make PHP4 compile fully and correctly by changing it to > this: > > { echo "configure: error: libjpeg.(a|so) not found." 1>&2; } Thanks James. That's unfortunate about the configure script being broken. I do remember some issues years ago, but would have thought they were cleared up already. Getting around the libjpeg problem is doable, either by your method or by using a symlink, as I did. What I'm not able to figure out is how to eliminate the -lxml - is there a similar hack to the configure script that would cover this? Much appreciated, --- Hans Zaunere President New York PHP http://nyphp.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
