mod_perl DSO problem

[Dean Gaudet <dg...@arctic.org>]

Ralf I tried to reproduce the problem using mod_cgi, which has handlers,
and mod_unique_id which has an init function.  The handlers are always
inserted, and the init function is always called.  So obviously there's
some detail that's different with mod_perl.

Does mod_perl do something like count how many times it has been
initialized and do nothing on the first pass?  Does it modify its handlers
after it has been initialized?

Dean

Re: mod_perl DSO problem

[Dan Jacobowitz <dr...@false.org>]

[ My apologies if half of this message is already covered, I just
joined this list, but I've been fixing mod_perl DSO problems constantly
for almost a week now. ]

There are two that I know of.  The one that I believe you are refering
to right now is the 'perl-script': handler not found problem, which is
the result of a bug in PERL_STACKED_HANDLERS.  For now at least, you
need to disable this to build as a DSO (beware, if you are building
1.12 with apxs, you need to edit apaci/mod_perl.config as Makefile.PL
does not yet handle apxs quite completely).  This bug has been reported
to the mod_perl people and they are looking in to it.

The other problem is the inability of a mod_perl DSO to load compiled
perl modules such as DBI.  This I traced, with help, to the way apache
and perl load modules: apache does not, in 1.3.0, use RTLD_GLOBAL, but
it seems that perl does.  So the modules are paradoxically being loaded
into a higher scope than their caller, and die attempting to initialize
for lack of visible perl symbols.  It's a bad hack, and probably not
the most appropriate solution, but change RTLD_NOW to RTLD_NOW |
RTLD_GLOBAL in os/unix/os.c fixes this bug.  Obviously, I would prefer
to avoid the namespace polution this causes, but it does seem to work.

Dan Jacobowitz
drow@false.org

who finally has experimental but working debian packages of mod_perl at
http://www.false.org/debian .