Re: ABI incompatibility problems between Perl versions
(Jens: re-adding you to the Cc list as I'm revisiting the File::FcntlLock
changes. I don't think this needs any action on your part though, at
least not yet.)
On Thu, May 29, 2014 at 11:50:05PM +0300, Niko Tyni wrote:
> On Wed, May 28, 2014 at 08:10:50AM +0200, Guillem Jover wrote:
> > On Tue, 2014-05-27 at 23:56:03 +0300, Niko Tyni wrote:
>
> > > In the fallback option, dpkg-dev should probably set PERL_DL_NONLAZY=1
> > > before trying to load File::FcntlLock::XS. See #479711.
> >
> > > (Hm, my preliminary testing indicates that 5.20.0 may introduce new
> > > challenges around PERL_DL_NONLAZY. Urgh. Will investigate.)
> >
> > Thanks, will take that into account! And I'm obviously interested in
> > any results from that investigation, which might imply having to switch
> > to always use the pure version for example. :)
>
> OK, it looks like may have a problem.
>
> Summary: Perl 5.18 segfaults when loading 5.20 XS modules, and Perl 5.20
> segfaults when loading 5.18 XS modules. This may break upgrades. The
> most robust fix I can think of is to start using a version specific
> 'vendorarch' directory instead of /usr/lib/perl5.
[...]
> (Guillem: unfortunately I think a package offering File::Fcntllock::Pure
> would be in the same set and we may be back at square one in that area...)
To expand on this a bit, File::Fcntllock::Pure is architecture dependent
but if it's installed into $Config{vendorarch}, it needs a hard perlapi-*
dependency in the future (see #750017). This dependency is what we've been
trying to avoid for the sake of dpkg-dev.
One thing we could do is to install File::Fcntllock::Pure in
$Config{vendorlib} (/usr/share/perl5) but change it to load the
architecture dependent pack/unpack templates from somewhere under
/usr/lib/, perhaps /usr/lib/<triplet>/libfile-fcntllock-perl or something
like that. This is something of a workaround, but I can't see why it
wouldn't work.
This way the perlapi-* dependency can be downgraded to a recommendation.
The above hack doesn't need to be visible to the dpkg-dev side at all AFAICS,
--
Niko Tyni ntyni@debian.org
Reply to: