Raphael Hertzog <[EMAIL PROTECTED]> writes: > Le Thu, Oct 08, 1998 at 08:54:46PM -0400, Michael Alan Dorman écrivait: > > Threaded perl and non-threaded perl are binary-incompatible at the > > extension level, meaning most compiled extensions must be > > distinguishable. > I think you're wrong. perl5.005 and perl5.005-thread are binary-compatible. > But in order to support threads, they had to break the > binary-compatibility beetween perl5.004 and perl5.005. That's it.
I think you should read the docs or follow the last couple of years of the perl5 development mailing list, as I have, before you suggest you know better than I. From doc/perldelta.pod: -----8<----- =head2 Binary Compatibility This version is NOT binary compatible with older versions. All extensions will need to be recompiled. Further binaries built with threads enabled are incompatible with binaries built without. This should largely be transparent to the user, as all binary incompatible configurations have their own unique architecture name, and extension binaries get installed at unique locations. This allows coexistence of several configurations in the same directory hierarchy. See F<INSTALL>. ----->8----- > > So, yes, I think Debian does have to honor this, and to make our perl > > gratuitously different (which is to say, having it look in > > /usr/lib/perl5) would be inviting calamity some time down the road. > Which in fact doesn't mean we cannot add /usr/lib/perl5 at the end > of @INC because architecture-dependant packages will be found > before. Possibly. But, also from doc/perldelta.pod: -----8<----- =head2 Perl Source Compatibility When none of the experimental features are enabled, there should be very few user-visible Perl source compatibility issues. If threads are enabled, then some caveats apply. C<@_> and C<$_> become lexical variables. The effect of this should be largely transparent to the user, but there are some boundary conditions under which user will need to be aware of the issues. For example, C<local(@_)> results in a "Can't localize lexical variable @_ ..." message. This may be enabled in a future version. Some new keywords have been introduced. These are generally expected to have very little impact on compatibility. See L<New C<INIT> keyword>, L<New C<lock> keyword>, and L<New C<qr//> operator>. Certain barewords are now reserved. Use of these will provoke a warning if you have asked for them with the C<-w> switch. See L<C<our> is now a reserved word>. ----->8----- So, there is no guarantee that existing perl modules may not trigger new warnings or other issues when run under the new perl. So, IMNSHO, the smarter thing to do would be to not add /usr/lib/perl5 to @INC. Mike.
