> > 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
32 matches
Mail list logo
