Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12985
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 25 Sep 2004 12:30:32 -0700
Message-ID: <41EE526EC2D3C74286415780D3BA9F87046F7BB4@ehost011-1.exch011.intermedia.net>
Thread-Topic: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
thread-index: AcSi1A4SdmnmJkwGSY+em2Wh2ZtVPQAYabDw
To: "James Devenish" <j-devenish@users.sourceforge.net>
Cc: <internals@lists.php.net>
Subject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
From: hans@nyphp.com ("Hans Zaunere")



> > 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.
>=20
> 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:
>=20
> { echo "configure: error: libjpeg.(a|so) not found." 1>&2; exit 1; }
>=20
> then you can make PHP4 compile fully and correctly by changing it to
> this:
>=20
> { 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