NYCPHP Meetup

[Hans Zaunere]

I'm sorry for the reply to myself folks, but does anyone have any hints
on the below?  It's a daunting post, I know, but also a daunting problem
:)  Thoughts on any of the points mentioned would be helpful.

Thanks all,

H

> -----Original Message-----
> From: talk-bounces at lists.nyphp.org
[mailto:talk-bounces at lists.nyphp.org] On Behalf Of Hans Zaunere
> Sent: Sunday, September 19, 2004 4:47 PM
> To: NYPHP Talk
> Subject: [nycphp-talk] ./configure, PHP, SuSE and the AMD64
> 
> 
> Hey everyone,
> 
> 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?  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.
> 
> -- 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 was 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
> 
> 
> _______________________________________________
> New York PHP Talk
> Supporting AMP Technology (Apache/MySQL/PHP)
> http://lists.nyphp.org/mailman/listinfo/talk
> http://www.newyorkphp.org