On Sat, May 17, 2008 at 12:02:31AM +0100, Nicholas Clark wrote:
> 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.
Thanks to everybody for the comments. I get the point about loading a
library with some unresolved symbols and only using those that resolve,
so the change could break working code.
How about just documenting this a bit more with something like the
attached patch? I still think it's unexpected that 'eval "require Foo"'
isn't enough to trap the error.
Some clarifications:
- I'm not familiar with the reasons for choosing
-Dvendorarch=/usr/lib/perl5, but I'll try to find out.
- the circumstances where this shows up in the Debian context are
somewhat a corner case where 'preinst upgrade' scripts that need XS
modules may get run with a new XS module but the old perl. The
package dependencies are not yet guaranteed to be met at the
'preinst' time, hence the 'eval "require Foo"' construct.
- the only time this has actually showed up so far is in the
Locale::gettext case, and that was solved in the same way as in the 5.6
-> 5.8 transition, namely making the Locale::gettext package pre-depend
on the new perl. However, there may be other similar cases that haven't
been discovered yet.
- the fatal error in this case is "undefined symbol: Perl_Istack_sp_ptr" and
happens in DynaLoader::bootstrap(), when calling the "${module}::bootstrap"
function installed by dl_install_xsub(). This is somewhat different to
the usual "call a function that doesn't resolve" case, but having both
raise an exception in Perl instead of finishing off the process would
certainly be good.
- the difference to the 5.6 -> 5.8 transition is that we have lots more
packages and preinst scripts now, but we don't have a good way to
identify which XS modules are needed by preinst scripts. It may well
be that Locale::gettext is the only one (like it apparently was in the
last transition), but we don't really know that yet.
Hm, one option could be to have the packaging system (dpkg) set
PERL_DL_NONLAZY=1 for all preinst script invocations...
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 7e7692e..66dc1ae 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -1562,6 +1562,10 @@ determining whether a particular feature (such as C<socket> or C<symlink>)
is implemented. It is also Perl's exception trapping mechanism, where
the die operator is used to raise exceptions.
+If you want to trap errors when loading an XS module, some problems with
+the binary interface (such as Perl version skew) may be fatal even with
+C<eval> unless C<$ENV{PERL_DL_NONLAZY}> is set. See L<perlrun>.
+
If the code to be executed doesn't vary, you may use the eval-BLOCK
form to trap run-time errors without incurring the penalty of
recompiling each time. The error, if any, is still returned in C<$@>.
