perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: DynaLoader's "special case"
Date Sun, 21 Nov 2004 16:41:31 GMT
Radoslaw Zielinski wrote:
> Stas Bekman <stas@stason.org> [19-11-2004 21:41]:
> 
>>Radoslaw Zielinski wrote:
>>
>>>Each time I upgrade perl and the DynaLoader's version changes, I have to
>>>rebuild mod_perl, or I'll get this error:
>>>  DynaLoader object version 1.05 does not match $DynaLoader::VERSION 1.06
> 
> [...]
> 
>>1) You need to have DynaLoader loaded before anything else, so you can 
>>load .so Perl extensions. That's why you see all those things. more 
>>explanation below.
> 
> 
> That's what I thought, but then gaim's perl plugins feature misleaded me
> (it just works without rebuilding and uses similar code; I failed to
> find out what's the difference).
> 
> So, as it's a p5p problem, I'll just switch to annoying them with perlbug.
> Sorry for blaming mod_perl too fast and thanks for the info. ;-)

You mean you want to suggest to make it a core feature of perl?

>>2) DynaLoader.a is statically linked with mod_perl.so, therefore every 
>>time you upgrade perl you need to rebuild mod_perl (which is not the only 
>>reason).
> 
> 
> I'm sure this particular problem is resolvable [1], but could you tell
> me more about the other reasons?

In order to load a shared library .so, one needs to load DynaLoader first, 
but since DynaLoader has its own .so lib, it's a chicken and egg problem. 
Therefore all embeded perl apps link statically against DynaLoader.a

> Why do I care: we're about to freeze PLD; if it's to be a stable,
> production-ready code base, it means I shouldn't include newer perls
> in the updates, or I'd break peoples hand-crafted mod_perl builds...

Normally DynaLoader is not updated, so it's usually not a problem. Though 
if you create a correct dependency between the DynaLoader version and 
mod_perl (and any other embed perl apps) you shouldn't have a problem.

> [1]  For example: since all embedded perl application link with -lperl,
>      the libperl.so itself could be linked with DynaLoader.a, so
>      applications wouldn't have to; other benefits: smaller apps,
>      smaller /usr/bin/perl (also appears to contain DynaLoader.a code).

I suppose so, but I haven't tried that, so I can't tell whether this will 
be easy.

For the future it's probably the best for perl to include that 
functionality internally. It's probably a good idea to ask at p5p, why its 
functionality was "sourced out" to an external module.

>>if you ever write an embedded perl app, which needs to load .pm files with 
>>.so extensions, you need to write:
> 
> [...]
> 
>>    eval_pv("require DynaLoader;", TRUE);
> 
> [...]
> 
> Thanks.  BTW, while I was getting this code to build, the line above
> caused a core dump when I invoked: "./my_embperl non-existing-file.pl".

well, it wasn't a real code, just a proof of concept. Email me offlist if 
you want to see a real program (I've a few small test programs that embed 
perl)



-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message