On Wed, Oct 13, 2004 at 03:23:51PM +0900, GOTO Masanori wrote: > At Tue, 12 Oct 2004 14:03:00 +0400, > Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote: > > > The bug _was_ in glibc, and not in php. It is not the job of php to > > > force you to have a non-buggy glibc installed.
> > This depends on point of view. > > If a library < X.Y does not provide a feature needed by a package, it's a > > common practice to make package depend on library (>= X.Y). Other > > packages, that don't need that library feature, don't need to depend on > > library (>= X.Y). > > The case with libapache-mod-php4 / glibc looks similar: glibc less than > > 2.3.2.ds1-17 does not provide neede functionality [due to a bug]. This > > affects libapache-mod-php4, but does no affect most (all?) other packages. > Note that you guys seems not know what dlopen() is. POSIX and SUS > says that dlclose() does not need to unmap libraries. So, it's debian > specific wishlist. I fixed this report because it's convenient for > the upgrade from woody to sarge, but it's not mandatory behavior. So, > another word, it's also libapache-mod-php4 bug during upgrade. Actually, the segfault was not caused by a bug in libapache-mod-php4; the bug is either a bug in openssl or in glibc, depending on your POV. Perhaps both ;), although the triggering event was certainly the introduction of a new upstream version of glibc -- in spite of the fact that there don't seem to have been any changes in the dlopen() code in that particular upstream version. -- Steve Langasek postmodern programmer
