On Thu, 10 Jul 2008, Reini Urban wrote:
> I've analyzed the symbols in the dll's and found the explanation and
> solution for this update problems. p5p and module authors need not to
> be concerned. It's a simple cygwin perl update problem.
>
> In short:
> All old perl-5.10.0-4 generated binary site_perl modules need to be
> recompiled with perl-5.10.0-5.
This should not be true: if the modules were compiled with 5.10.0-4, then
they should work with 5.10.0-5.
> They are not ABI cross-compatible with the new vendor and archlib modules.
>
> Explanation:
> perl-5.10.0-5 is based on patchlevel 34065, perl-5.10.0-4 was based on
> plain 5.10.0 with a lot of patches.
>
> perl-5.10.0-5 adds a new utf8 handling of strings via a new
> newSVpvn_flags function
> sv.h: #define newSVpvn_utf8(s, len, u) newSVpvn_flags((s), (len), (u)
> ? SVf_UTF8 : 0)
> perl-5.10.0-4 does not contain newSVpvn_utf8 nor newSVpvn_flags.
>
> So any new XS module using strings may not call an old perl-5.10.0-4 dll,
> which
> does not contain the _utf8 and _flags functions.
So how do you end up with a site_perl compiled against 5.10.0-5, but
running with 5.10.0-4? You installed the new site_perl into an older
Perl installation?
> Solution:
> # delete all old site packages with dll's and reinstall them
> for pack in $(find /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto \
> -name .packlist \! -newer /bin/perl.exe);
> do
> grep .dll $pack && rm -f $(cat $pack)
> done | \
> perl -MCPAN -ne'
> s|/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/(.+?)/\w+\.dll$|$1|;
> s|/|::|g; push @p, $_; END {install(@p) }'
>
> should recompile them all.
But that would compile them with 5.10.0-4 again, right. Wouldn't it be
better to replace your 5.10.0-4 dll with the 5.10.0-5 dll?
I guess I'm confused about how you ended up in this situation in the
first place.
Cheers,
-Jan
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
