in reply to Two versions of Perl causing coredump

Presumably, your two Perl versions aren't binary compatible. XML::LibXML isn't a pure-Perl module, so its associated compiled components (shared libraries) have to match the perl binary...

What do /usr/bin/perl -v and /usr/local/bin/perl -v say?

Examples of incompatibilities are: different major version of Perl (e.g. 5.8 vs. 5.10), 32-bit vs. 64-bit, built with/without threading support.

How to resolve this?

Either install separate versions of XML::LibXML - each one built for the respective perl binary (and make sure to dynamically set the correct lib paths (@INC) if you install them in non-standard places), or make sure the appropriate perl binary is always being used with the one existing version of XML::LibXML.

Replies are listed 'Best First'.
Re^2: Two versions of Perl causing coredump
by DrHyde (Prior) on Oct 12, 2009 at 09:41 UTC

    An important point that some people forget is that when the tests for your code get run, they need to test against the correct version of perl. Both for this reason, but also because, well, if you don't, then your code isn't properly tested. For this reason, if any of your tests ever need to run another perl process, they need to be careful to get the right perl!

    You can't just system(qw(perl ...)) as that will pick up the first perl executable in the path, which may not be the build of perl that the user is interested in. The best way of getting this is: 

    use Config;
system($Config{perlpath}, qw(...));

    [download]
    and even that has some weird edge-cases. To really get the right perl interpreter, use Probe::Perl's find_perl_interpreter method.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom