Subject: Re: CVS commit: pkgsrc
To: Todd Vierling <email@example.com>
From: Johnny C. Lam <firstname.lastname@example.org>
Date: 03/07/2001 13:07:48
Todd Vierling <email@example.com> writes:
> On Tue, 6 Mar 2001, Todd Vierling wrote:
> : BTW, I submit that several php3-* modules work Just Fine with interlibrary
> : dependencies, so they *should* work with php4-imap too. That means there's
> : evidently something wrong in the php4-imap build and/or symbol conflicts
> : between php4, php4-imap, imap-uw, and/or libc.
> I'm sorry if this came out a bit harsh (as has been told to me by a couple
> people). I was trying to express a point, probably a little too
> If you need help addressing these changes, however, please let me know.
Apology accepted. I don't want to dump egos over a 3rd party package
in NetBSD pkgsrc. And I'd certainly like to fix things in the right
way and will defer to your greater expertise in these matters.
I think the original apache package from the 1.2.x days had problems
with loadable shared modules as apache needed to explicitly load the
SSL libraries prior to loading mod_ssl.so. I'll describe the current
problem with apache, php4, and php4-imap as I can best recall:
If the php CGI binary was directly invoked, then there were no
problems. The problems only arose when using mod_php4. If the
php.ini file didn't load any shared PHP modules, then apache loaded
mod_php4.so just fine and could process .php files. The original
php4-imap module (imap.so) was dynamically linked against
libc-client.so, libssl.so and libcrypto.so. If php.ini loaded
imap.so, then apache would silently return with no error messages and
no core dump. If libc-client.so was explicitly loaded (via LoadFile)
before mod_php4.so, then apache would refuse to start due to
unresolved symbols in libc-client.so that are defined in imap.so.
libc-client.so expects the client IMAP application to define various
functions that are declared in libc-client.so. This is what lead to
the original workaround of linking libc-client_pic.a directly in to
imap.so. With this change, apache would load mod_php4.so and
correctly process pages with PHP4-IMAP functions.
Something similar also happens with the php4-pgsql module (pgsql.so).
Apache won't start unless libpg.so is explicitly loaded by httpd.conf,
despite the fact the pgsql.so is dynamically linked against libpg.so.
What's the right way to track down the source of the problem? I'd
like to fix things, but on my 20010206 i386 snapshot system, I'm
having problems getting apache to even start:
so I'm stuck.
-- Johnny C. Lam <firstname.lastname@example.org>
Department of Statistics, Carnegie Mellon University