perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: DynaLoader's "special case"
Date Sun, 21 Nov 2004 17:24:24 GMT
Radoslaw Zielinski wrote:
> Stas Bekman <> [21-11-2004 17:41]:
>>Radoslaw Zielinski wrote:
> [...]
>>>So, as it's a p5p problem, I'll just switch to annoying them with perlbug.
> [...]
>>You mean you want to suggest to make it a core feature of perl?
> I'm not sure how do you define a "core feature"...  I want to show
> a problem (breaking the binary compatibility) and suggest a solution.

To have the functionality of Dynaloader.a be built-in in libperl.(so|a)

>>>>2) DynaLoader.a is statically linked with, therefore every 
>>>>time you upgrade perl you need to rebuild mod_perl (which is not the only

>>>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
> DynaLoader doesn't have a *.so lib, only *.a and *.pm (at least on my
> system):

Yes, sorry, it can't have .so precisely for the explained reason.

> But what I was aksking: what are the other reasons you mentioned for
> rebuilding mod_perl after perl upgrade?

You mean unrelated to the Dynaloader issue? Usually the main reason is 
that a new perl might be slightly built slightly different. I'm not 
talking about the binary compatibility, which for example all 5.8.x series 
preserve (well, almost, 5.8.1 wasn't the case). I'm talking about things 
like, linking against a different library (statically or dynamically) e.g. 
libdb or libgdbm, or not linking against it. Using a different compile 
option, extending @INC and more. So as long as the upgraded perl is 
exactly the same, there should be no need to upgrade mod_perl. But many 
times this is not the case. You can find plenty of examples in the mailing 
list archives, posted over the last 8 years.

>>>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 
> Well, it is in 5.8.6-rc1 and was at least once more (5.8.3?) in the
> 5.8.x line.

Right, but the dependency rule should have handled that.

>>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.
> Oh well, I did that yesterday, searching for affected applications, and
> adding "Requires: perl(DynaLoader) = %(perl -MDynaLoader -e 'print
> DynaLoader->VERSION)" to the *.spec files.  A friend laughed at me to
> wash my hands after digging this shit, when he saw what I'm doing.

Welcome to the club, Radoslaw.

> But I also want to support hand-made builds (people may not like the way
> we distribute apache and mod_perl) and (maybe) propietary applications
> embedding perl, not only my extra-tuned RPMs.


>>>[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).
>>I suppose so, but I haven't tried that, so I can't tell whether this will 
>>be easy.
> I'm in the middle of patching Makefile.SH right now.  Almost works:
>   $ LD_LIBRARY_PATH=$PWD ./perl
>   ./perl: symbol lookup error: ./perl: undefined symbol: boot_DynaLoader
> ;->


It's probably the best to rework it to replace .xs files with .c and have 
it be part of But I suppose this won't happen in 5.8.6. Ask at 
p5p though.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message