In message <[EMAIL PROTECTED]>
on Fri, Sep 24, 2004 at 07:21:45PM -0700, Hans Zaunere wrote:
> 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; }
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
