httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: mod_perl DSO problem
Date Mon, 22 Jun 1998 09:20:27 GMT

In article <> you wrote:

> 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.

Yes, I know this -DNO_PERL_STACKED_HANDLERS issue and I tried it.  Actually
some "make test" parts are then fine, but there are still about 40% of them
failing. With PERL_STACKED_HANDLERS about 90% are failing. So yes, there is a
bug in mod_perl around PERL_STACKED_HANDLERS but there have to a nother
somewhere. Whether inside Apache or mod_perl I don't know. From my and Deans
tests we would say inside mod_perl. OTOH mod_perl is a really complex module
and perhaps the other modules are too "trivial" to show the error. I don't

> 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.

Yes, that's the third problem. Its related to Apache but we have to be
carefully here with the RTLD_XXX stuff because not all systems support all
                                       Ralf S. Engelschall

View raw message