Re: php4 not in testing
Hi Russell,
On Fri, 8 Jun 2001, Russell Coker wrote:
> > I have to make a list of known working configurations somewhere. This
> > is really starting to annoy me. Probably only option will be to link
> > everything staticaly. And into one big libphp4.so to be on the safe
> > side.
> Why is this? Why can't it just work?
In the past, a big issue with PHP modules was that some of them depended on
libs that were compiled with pthreads, and being loaded by an application
(Apache) which was not. Is this possibly related to the current problem?
Has this issue been raised with the upstream developers? I haven't been
following PHP4 upstream much lately, but I've never run into such problems of
fragility on other non-Debian systems where I make heavy use of PHP (and DSO
extensions, as well). I'm curious to know if I've just been lucky, or if this
problem really only happens on Debian.
As to compiling a list of known working configurations, Petr, I'd personally
be more interested in getting ahold of a minimalist configuration that
/fails/. There may be multiple library bugs here, but at least if we can see
the most basic configuration that doesn't work, we have a better chance of
being able to get away with the everything-in-one-static-build approach down
the line.
> If making one big libphp4.so that provides everything is the solution to
> these problems then I think that is what has to be done.
Yep. Not pretty, but possibly the best available solution at this point. :/
> The current state of PHP4 is very fragile, if there is any viable
> alternative then I think that we should not release software in that
> state. PHP3 is a very viable alternative and works fine. It seems that
> most PHP software will with with either version.
It's not a viable option for me, I'm afraid... I'm looking to migrate some
webhosting servers to Debian, but we (and our customers) have code that makes
heavy use of PHP4's enhanced language features.
Cheers,
Steve Langasek
postmodern programmer
Reply to: