perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radoslaw Zielinski <>
Subject Re: DynaLoader's "special case"
Date Sun, 21 Nov 2004 12:20:30 GMT
Stas Bekman <> [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. ;-)

> 2) DynaLoader.a is statically linked with, 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?

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

[1]  For example: since all embedded perl application link with -lperl,
     the 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).

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

Radosław Zieliński <>
[ GPG key: ]

View raw message