|Perl: the Markov chain saw|
Re: combination of multiple installed Perls and some environment variables cause segfaultsby Anonymous Monk
|on Apr 06, 2013 at 08:22 UTC||Need Help??|
Question 1: Shouldn't PERL_DL_NONLAZY be helpfully causing these sorts of errors, not preventing them like it seems to be doing?
PERL_DL_NONLAZY has nothing to do with it, you're mixing two perl versions which aren't compatible, it will never work
5.8.x, 5.10.x, 5.12.x, 5.14.x, 5.16.x ... aren't compatible, you can't load .dll/.so modules compiled for one version in another
5.10.0 not compatibile with 5.10.1, 5.10.0 has known bugs
Question 2: Should my directory structure in ~/local/lib/perl5 have perl-version-specific directories, or is that something I would have had to create manually, or does that not matter in this case?
If you're thinking perl5.16.1 or some such, I think you'd have to add that yourself
Question 3: The segfaulting seems to be caused because the PERL5LIB prepends a perl-5.14.2 directory to @INC, a ReadKey.pm and ReadKey.bundle are found there, but the perl 5.10 called by the script or by me manually sees a different symbol table in that .bundle file than it is expecting. How can I avoid that, what do you recommend for a path forward out of this mess? Let's assume I can't (or won't) change the Netpbm source code to have the perl scripts start with #!/usr/bin/env perl instead.
Install Netpbm into your install_base, add the ..\snacks\bin in your install_base first in path, netpbm will have correct path, problem will be over
Or make the 5.14 perl first in your path
One perl in the path at a time, any PERL* env vars should match first perl in path, no mixing allowed
Some links on debugging these types of problems