Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: <internals@lists.php.net>
Date: Sat, 25 Sep 2004 13:12:51 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcSi1A4SdmnmJkwGSY+em2Wh2ZtVPQAYabDwAACjK9A=
In-Reply-To: <41EE526EC2D3C74286415780D3BA9F87046F7BB4@ehost011-1.exch011.intermedia.net>
Message-ID: <auto-000000439561@bobsilva.com>
Subject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
From: junkmail@bobsilva.com ("Robert Silva")
References: <41EE526EC2D3C74286415780D3BA9F87046F7BB4@ehost011-1.exch011.intermedia.net>

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:hans@nyphp.com] 
Sent: Saturday, September 25, 2004 12:31 PM
To: James Devenish
Cc: internals@lists.php.net
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