perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radoslaw Zielinski <ra...@karnet.pl>
Subject Re: DynaLoader's "special case"
Date Sun, 21 Nov 2004 23:28:47 GMT
Stas Bekman <stas@stason.org> [21-11-2004 18:24]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <stas@stason.org> [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 <radek@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]

Mime
View raw message