# ./configure, PHP, SuSE and the AMD64

- Thread: https://externals.io/message/14054
- Original archive: https://news-web.php.net/php.internals/14054
- Started by Hans Zaunere on 2004-12-12T22:56:25+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #14054 — Hans Zaunere — 2004-12-12T22:56:25+00:00

URL: https://externals.io/message/14054#14054

> > […]
most of
> > […]
pick
> > […]
/usr/lib64
> > […]
know if
> > […]
> 
> Things look to work in the latest CVS checkouts (2004-12-12) of both
> php4 and php5.  I've typically been using this ./configure for
testing:
> 
> ./configure --prefix=/usr/local/php
> --with-apxs=/usr/local/apache/bin/apxs --with-openssl --with-zlib
> --with-bz2
> 
> A quick recap:
> 
> -- released PHP versions (4.3.9 and 5.0.2) can't locate any libs not
in
> /lib or /usr/lib.  For 64bit systems, which put 64bit versions of
> libraries in /lib64 and /usr/lib64, ./configure or compile breaks.
> 
> -- the latest RCs of both 4.3.10 and 5.0.3 work properly, and will
> always use libs in /lib64 or /usr/lib64, and ./configure and compile
> work correctly.
> 
> > […]
--with-libdir
> > […]
> 
> One caveat, however, is that --with-libdir doesn't seem to have any
> effect.  In both 4 and 5 CVS versions, supplying --with-libdir=lib64,
> --with-libdir=lib, or not specifying it all, have no effect.  lib64
> libraries are always used.
> 
> While an academic problem (ie, why would I want to specify lib on a
> lib64 system), there doesn't seem to be any way to force the 32 bit
libs
> on a 64bit system.  Even if both 32bit and 64bit versions of a library
> exist on the system, the 64bit libs will always be used.
> 
> A strange, unrelated problem.  After a successful make, a make install
> fails for both 4 and 5 from CVS.  The error:
> 
> cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so
> cp: cannot stat `libs/libphp4.so': No such file or directory
> 
> When I look at libs, the only file is libphp4.  A rename of libphp4 to
> libphp4.so and then make install works.  For PHP 5, this is of course
> libphp5.  Any insight into this would be appreciated.
> 
> Thanks Joe and everyone - this seems to get things working for both 4
> and 5.  I'm going to continue testing, and then document all of this
for
> future generations, and will keep you in the loop if something else
> looks wrong.

Some more interesting things that threw me off at first.  While 4.3.10
and 5.0.3 do handle lib64 much better than previous versions, and will
compile with the basic extensions enabled on a lib64 only system, only
HEAD really implements --with-libdir.  These versions will break when
more extensions are enabled.

On HEAD, with-libdir has a significant effect with some of the
extensions.

However, with HEAD as of two minutes ago, it appears that the GD
extension isn't fully aware of PHP_LIBDIR.  The supporting jpeg, png,
xpm, etc. libs are found correctly under /usr/lib64, but libgd itself
isn't.

Looking at ext/gd/config.m4, the trouble might be around the for loop on
line 366 (there's no hint of PHP_LIBDIR).  This results in the
./configure time error of:

configure: error: Unable to find libgd.(a|so) anywhere under /usr

Even though:

# ldconfig -p | grep -i libgd
        libgd.so.2 (libc6,x86-64) => /usr/lib64/libgd.so.2
        libgd.so (libc6,x86-64) => /usr/lib64/libgd.so

If I take the GD stuff out of ./configure, I then am using this:

./configure --with-libdir=lib64 --prefix=/usr/local/php \
--with-apxs=/usr/local/apache/bin/apxs \
--with-openssl \
--with-zlib \
--enable-bcmath \
--with-bz2 \
--enable-calendar \
--with-curl \
--enable-dio \
--enable-exif \
--enable-ftp \
--with-gettext \
--with-gmp \
--with-mcrypt \
--with-mhash \
--with-mysql=/usr \
--with-mysqli=/usr/bin/mysql_config \
--enable-shmop \
--enable-soap \
--enable-sockets \
--without-sqlite \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--with-xmlrpc \
--with-xsl


Which works great, and looks like it wants to compile; except for the
seemingly unrelated bug in HEAD that I noted in my previous post.

Thanks,


---
Hans Zaunere
President, Founder
New York PHP
http://www.nyphp.org

---

## #14057 — Joe Orton — 2004-12-13T10:34:03+00:00

URL: https://externals.io/message/14054#14057 · In reply to: #14054

> Some more interesting things that threw me off at first.  While 4.3.10
> and 5.0.3 do handle lib64 much better than previous versions, and will
> compile with the basic extensions enabled on a lib64 only system, only
> HEAD really implements --with-libdir.  These versions will break when
> more extensions are enabled.

4.3.10 and 5.0.3 don't have any lib64-type fixes in AFAIK - they should
work no better or worse than previous versions: i.e. it should be OK
until you start enabling any of the extensions which require libraries
out of /usr/lib{,64}.

> On HEAD, with-libdir has a significant effect with some of the
> extensions.
> 
> However, with HEAD as of two minutes ago, it appears that the GD
> extension isn't fully aware of PHP_LIBDIR.  The supporting jpeg, png,
> xpm, etc. libs are found correctly under /usr/lib64, but libgd itself
> isn't.
> 
> Looking at ext/gd/config.m4, the trouble might be around the for loop on
> line 366 (there's no hint of PHP_LIBDIR).  This results in the
> ./configure time error of:
> 
> configure: error: Unable to find libgd.(a|so) anywhere under /usr

OK, I've just fixed that.  Thanks for testing this stuff out!

Regards,

joe