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 23:28:47 GMT
Stas Bekman <> [21-11-2004 18:24]:
> 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)

Then yes.  Since it's in /usr/bin/perl anyway, it's not a big revolution.

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

Ah, then fine.  Build options are under my control; I thought that maybe
mod_perl is using some weird perl features, not covered by the backward
compatibility policy.

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

And I need a complex solution, so I patched that Makefile.SH.


Bug #32539 it is.

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

View raw message