On Fri, May 16, 2008 at 03:04:21PM +0200, Rafael Garcia-Suarez wrote:
> 2008/5/16 Gisle Aas <[EMAIL PROTECTED]>:
> > Another objection is that you might simply want to load the module and use
> > some function that does resolve. Making require always fail if some
> > functions doesn't resolve prevent this for working at all. I think the user
> > better set PERL_DL_NONLAZY themselves if that's what they want.
>
> Good point.
Changing this doesn't feel right. I suspect that Gisle's reasoning is part of
my gut feeling on this. Lazy has been the default since 5.002 (1996), and
prior to that was the only option. I never remember this being a problem.
On Fri, May 16, 2008 at 08:31:24AM -0400, Andy Dougherty wrote:
> On Thu, 15 May 2008, Niko Tyni wrote:
>
> > Hi p5p,
> >
> > we're currently doing the 5.8.8 -> 5.10.0 transition in Debian, and the
> > binary incompatibility in the XS module interface is biting us in an
> > unexpected way.
> >
> > In a nutshell, it's possible during the upgrade to temporarily end up
> > in a state where perl is still 5.8.8, but some XS modules are already
> > the new ones (ie. built for 5.10.0).
>
> The default perl installation was deliberately designed to avoid just this
> problem by including a version-specific directory-path in
> $Config{vendorarch}. That way perl-5.8.8 would not try to load
> incompatible perl-5.10.0 modules. Debian's build script deliberately does
> not include a version-specific $Config{vendorarch}. It might be worth
> reviewing that decision.
Perl 5.6.x and Perl 5.8.x are not binary compatible either, yet Debian
upgraded from 5.6.x to 5.8.x without hitting this issue. What changed?
DynaLoader certainly didn't, hence why I'm highly suspicious that changing
it is not the right solution here.
Nicholas Clark
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
