Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:13327
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: Wed, 13 Oct 2004 10:05:32 -0700
Message-ID: <41EE526EC2D3C74286415780D3BA9F8704F13AAA@ehost011-1.exch011.intermedia.net>
Thread-Topic: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
thread-index: AcSw9EdY9PMFXPPiSJ2LP40UlxiKxwAT//GA
To: "Derick Rethans" <derick@php.net>
Cc: <internals@lists.php.net>
Subject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
From: hans@nyphp.com ("Hans Zaunere")


> > > > The patch shown is what SuSE did for their RPM distribution of
PHP.
> > > >
> > > > One solution may be with the --with-<module>=3D directive is to
assume that
> > > > dir may be an absolute path as well.
> > > >
> > > > --with-domxml=3D/usr/lib64
> > >
> > > No, this is too different from what PHP always has been doing...
thus a
> > > bad idea.
> >
> > Out of curiosity, what has PHP been doing?  I always see people
specify
> > a full directory, which typically works.
>=20
> That's a co-incidence then, as this:
> --with-domxml=3D/usr/lib
> is NOT working as you might think. You always need to do:
> --with-domxml=3D/usr
> as the php checks add /lib for you.

Sorry for the confusion.  Because the previous post mentioned absolute
paths, above, I took it to mean with a leading slash.  As you mention,
/usr or /usr/local/mysql is the way to do it currently, but still there
are some inconsistencies, per below.

> > As I mentioned in my original post, --with-module and
> > --with-module-dir seem to have some inconsistencies themselves as
> > well.  What is the behavior?
>=20
> Where are the inconsistencies, can you point those out?

Here are some notes additions from my previous post.

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).

This just seems right-out broken...

> --with-zlib=3D/usr  (this works - but what if I want to
> force the 64bit library version, in /usr/lib64?)

This is seems to be related to this thread, specifically lib64.

> --with-bz2=3D/usr/lib64  (and this also works - which you
> would think it shouldn't, compared to the zlib above?)

Just confusion... perhaps on my part, or inconsistencies in the way
./configure works.

> And lastly, take these:
>
> --with-curl=3D/usr/lib64
> --with-zlib-dir=3D/usr/lib64
>
> Both seem to work (so far).  So what is the difference
> between a directive having the -dir suffix and not?

Compare --with-zlib and --with-zlib-dir, per above.  Things sometimes
"work" (meaning there are no obvious errors) and sometimes not; so how
should the two be used?  What does the suffix -dir mean and how should
it be used?

> > Going back to 64bit platforms, this is going to be a problem moving
> > forward.  AMD64 is all over the place, and thus having lib and lib64
> > directories.  While a SuSE patch works for SuSE, what about other
AMD64
> > distros?  What happens on FreeBSD?  Can PHP's ./configure be fixed
to be
> > flexible, as a ./configure script should be, or will platform
specific
> > hacks need to be made (which seems counter-intuitive, since that's
what
> > ./configure is for).
>=20
> PHP's ./configure needs to be fixed of course, though for now the
> suggested patches are a bit suboptimal iirc. I would like to give it a

Agreed. ./configure should 1) have defaults of lib's locations  2) use
system linker variables  and most importantly  3) allow specific
directories to be specified during ./configure time.

> shot, but I'll need to have access to a linux running on 64bit first
:)

That's not a problem, see follow-up message.

Thanks Derick,

H