> > 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
On Sun, Dec 12, 2004 at 02:56:25PM -0800, Hans Zaunere wrote:
> 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 impl
> > I've committed the core changes to add --with-libdir and updated
most of
> > the extensions which I could test here.
> >
> > Hans, can you test out HEAD on your SLES box? You should just use
> > --with-libdir=lib64 and then e.g. --with-mysql=/usr will correctly
pick
> > up the system MySQL li
> >-- 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.
>
> Interesting to hear that 4.3.10 works as it hasn't been touched at
all?
> (I might have missed some fix, but AFAICT, this wa
On Sun, 12 Dec 2004, Hans Zaunere wrote:
>-- 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.
Interesting to hear that 4.3.10 works as it hasn't been touched at all?
(I might have missed
> I've committed the core changes to add --with-libdir and updated most
of
> the extensions which I could test here.
>
> Hans, can you test out HEAD on your SLES box? You should just use
> --with-libdir=lib64 and then e.g. --with-mysql=/usr will correctly
pick
> up the system MySQL libraries in
I've committed the core changes to add --with-libdir and updated most of
the extensions which I could test here.
Hans, can you test out HEAD on your SLES box? You should just use
--with-libdir=lib64 and then e.g. --with-mysql=/usr will correctly pick
up the system MySQL libraries in /usr/lib64.
On Sun, Oct 31, 2004 at 01:18:49PM -0800, Hans Zaunere wrote:
> Has anything been committed yet? I'd like to test some things out once
> it has...
No, sorry, not yet. Since it seems nobody has any objections I will
commit the changes to HEAD later this week.
joe
--
PHP Internals - PHP Runtime
> > On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
> > > AFAIK Joe is going to commit his patch, but we need to "fix" it
for the
> > > PECL extensions too if applicable.
> >
> > I was kind of waiting for Sascha to review it... do you want me to
> > commit it now? PECL extensions
On Fri, 22 Oct 2004, Joe Orton wrote:
> On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
> > AFAIK Joe is going to commit his patch, but we need to "fix" it for the
> > PECL extensions too if applicable.
>
> I was kind of waiting for Sascha to review it... do you want me to
> commit
On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
> AFAIK Joe is going to commit his patch, but we need to "fix" it for the
> PECL extensions too if applicable.
I was kind of waiting for Sascha to review it... do you want me to
commit it now? PECL extensions (or any autoconf code in
> > For #2, per Robert Silva's post:
> >
> > "For #2, I believe he is referring to searching LD_LIBRARY_PATH
> > directories for libraries rather than hardcoding /lib everywhere
(which
> > is how its done now)."
>
> Unfortunately it's not that easy from what I remember.
>
> > > with as it is com
On Fri, 22 Oct 2004, Hans Zaunere wrote:
> For #2, per Robert Silva's post:
>
> "For #2, I believe he is referring to searching LD_LIBRARY_PATH
> directories for libraries rather than hardcoding /lib everywhere (which
> is how its done now)."
Unfortunately it's not that easy from what I remember.
> > > > 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?
> > >
> > > Where are the inconsistencies, can you point those out?
> >
> > Here are some notes additions from my previous p
On Wed, Oct 13, 2004 at 05:12:22PM +0200, Sascha Schumann wrote:
> On Wed, 13 Oct 2004, Joe Orton wrote:
> >So other than vague slurs on OS sanity, are there objections to
> >committing my --with-libdir patch to HEAD?
>
> I will look at it later.
Have you had a chance to look at it, Sascha?
Hans Zaunere
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
On Wed, 13 Oct 2004, Hans Zaunere wrote:
> > > As I mentioned in my original post, --with-module and
> > > --with-module-dir seem to have some inconsistencies themselves as
> >
On Wed, 13 Oct 2004, Hans Zaunere wrote:
> > > 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?
> >
> > Where are the inconsistencies, can you point those out?
>
> Here are some notes ad
> > > > The patch shown is what SuSE did for their RPM distribution of
PHP.
> > > >
> > > > One solution may be with the --with-= directive is to
assume that
> > > > dir may be an absolute path as well.
> > > >
> > > > --with-domxml=/usr/lib64
> > >
> > > No, this is too different from what PHP al
On Wed, 13 Oct 2004, Joe Orton wrote:
> > FreeBSD amd64 installs its libraries into /usr/lib, as any
> > sane OS does.
>
> So other than vague slurs on OS sanity,
Hey, even Debian sid does it ;-)
> are there objections to
> committing my --with-libdir patch to HEAD?
>
> http://news.php.n
On Wed, 13 Oct 2004, Joe Orton wrote:
On Wed, Oct 13, 2004 at 09:55:15AM +0200, Sascha Schumann wrote:
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
That is hardly a new issue. Irix and other systems hav
On Wed, Oct 13, 2004 at 09:55:15AM +0200, Sascha Schumann wrote:
> >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
>
> That is hardly a new issue. Irix and other systems have had
> different lib d
> > 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
>
> That is hardly a new issue. Irix and other systems have had
> different lib directories for many years. The users of those
> systems
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
That is hardly a new issue. Irix and other systems have had
different lib directories for many years. The users of those
systems always coped with t
Hans Zaunere wrote:
> I notice a number of strange issues while running ./configure.
For what it's worth: I never experienced any of the problems you
describe with PHP (PHP_4_3, PHP_5_0, HEAD) on my AMD64 box which runs on
Gentoo Linux (~amd64).
--
Sebastian Bergmann http
On Tue, 12 Oct 2004, Hans Zaunere wrote:
>
> > > The patch shown is what SuSE did for their RPM distribution of PHP.
> > >
> > > One solution may be with the --with-= directive is to assume
> that
> > > dir may be an absolute path as well.
> > >
> > > --with-domxml=/usr/lib64
> >
> > No, this is t
> > The patch shown is what SuSE did for their RPM distribution of PHP.
> >
> > One solution may be with the --with-= directive is to assume
that
> > dir may be an absolute path as well.
> >
> > --with-domxml=/usr/lib64
>
> No, this is too different from what PHP always has been doing... thus
a
>
On Mon, Sep 27, 2004 at 08:36:49PM +0200, Derick Rethans wrote:
> On Mon, 27 Sep 2004, Joe Orton wrote:
> > On Mon, Sep 27, 2004 at 10:13:04AM +0200, Derick Rethans wrote:
> > > I think this patch is the way to go for this, but it won't address
> > > issues when you mix both 64bit and 32bit librari
In message <[EMAIL PROTECTED]>
on Sat, Sep 25, 2004 at 01:12:15PM -0700, Rasmus Lerdorf wrote:
> Can't you just do:
>
> LDFLAGS=-L/usr/lib64 ./configure ...
>
> CPPFLAGS for compile-time stuff
The compiler and linker have no problem. The problem is that the
./configure script does its *own* li
ject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
> > 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 t
On Sat, 25 Sep 2004, James Devenish wrote:
> 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
> > confus
> > 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
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 ./c
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, wit
33 matches
Mail list logo
