I'm doing a PHP compile for New York PHP's AMD64 Project. The goal is
to enable all the hottest and modern extensions, and then let people
hack with their favorite extensions to find problems and bugs under a
64bit architecture. We're running SuSE Enterprise 9.1 on a dual AMD64
Opteron box, with 4GB of RAM.
I notice a number of strange issues while running ./configure. Most of
which I've been able to work through, and which I've documented to be
revisited later (the complete process of setting the box up is
documented and will be on nyphp.org when completed).
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.
I can post the entire ./configure if requested, but this is pertinent at
this point:
....<snip>
--with-dom=/usr/lib64 --with-zlib-dir=/usr/lib64 \
--with-dom-xslt=/usr/lib64 --with-dom-exslt=/usr/lib64 \
--enable-exif --enable-ftp \
--with-gd=/usr/lib64 --with-jpeg-dir=/usr/lib64 \
--with-png-dir=/usr/lib64 --with-zlib-dir=/usr/lib64 \
--with-freetype-dir=/usr/lib64 \
....</snip>
The ./configure stops with this error message:
checking whether to enable truetype string function in GD... no
checking whether to enable JIS-mapped Japanese font support in GD... no
checking for jpeg_read_header in -ljpeg... no
configure: error: Problem with libjpeg.(a|so). Please check config.log
for more information.
And config.log contains this relevant snippet at the end:
configure:29794: checking whether to enable truetype string function in
GD
configure:29819: checking whether to enable JIS-mapped Japanese font
support in GD
configure:31813: checking for jpeg_read_header in -ljpeg
configure:31832: gcc -o conftest -g -O2 -Wl,-rpath,/usr/lib64
-L/usr/lib64 -Wl,-rpath,/usr/ssl/lib -L/usr/ssl/lib conftest.c -ljpeg
-lexslt -lxml -lxslt -lz -lcurl -lbz2 -lz -lresolv -lm -ldl -lnsl -lssl
-lcrypto -ldl -lcurl -lz -lssl -lcrypto -ldl -lxml2 -lz -lm 1>&5
usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux
/bin/ld: cannot find -lxml
collect2: ld returned 1 exit status
configure: failed program was:
#line 31821 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char jpeg_read_header();
int main() {
jpeg_read_header();
return 0;
}
At first glance, it appears the problem is in libjpeg - but it's not.
Notice "cannot find -lxml"
I have only libxml2 installed:
amd:~/INSTALLED/php-4.3.8 # ldconfig -p | grep -i libxml
libxml2.so.2 (libc6,x86-64) => /usr/lib64/libxml2.so.2
libxml2.so.2 (libc6) => /usr/lib/libxml2.so.2
libxml2.so (libc6,x86-64) => /usr/lib64/libxml2.so
amd:~/INSTALLED/php-4.3.8 #
So why is it looking for -lxml? I haven't been able to spot a --without
flag that does the trick, either. There is also the link flag of
-lxml2, which is correct. Am I missing something here, or do I really
need to install libxml in addition to libxml2 (which totally doesn't
seem right)?
So that's the main question right now.
There are some other issues that I've mostly worked around, but figure
I'll drop by this list for additional comments and thoughts. And, they
might add some complications to the issue above.
-- 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.
After the RPM's install, ./configure couldn't find libjpeg, even though
ldconfig knew where it was - it is in /usr/lib64. The error:
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.
-- On a similar note is the specifying of specific directories. In the
./configure snippet above, you'll notice I typically use /usr/lib64 with
any --with directive. I know this might be wrong, but using /usr
doesn't help either (for instance, --with-jpeg-dir=/usr doesn't work).
In fact, there appear to be some inconstancies, and certainly some
questions:
--with-openssl (must not have any directory after it, which isn't
inline with what ./configure --help says).
--with-zlib=/usr (this works - but what if I want to force the 64bit
library version, in /usr/lib64?)
--with-bz2=/usr/lib64 (and this also works - which you would think it
shouldn't, compared to the zlib above?)
And lastly, take these:
--with-curl=/usr/lib64
--with-zlib-dir=/usr/lib64
Both seem to work (so far). So what is the difference between a
directive having the -dir suffix and not?
For most compiles, I just set everything to /usr/local and /usr and it
works. Occasionally, there are problems, but they are usually easily
resolved with ldconfig runs, etc. However, in this case, having lib64
seems to have added another level of complexities and possible
permutations of what doing The Right Thing really is. Are these
potentially bugs and mis-documentations, or simply me missing the
obvious?
Any thoughts appreciated, thanks all,
---
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
