Re: combination of multiple installed Perls and some environment variables cause segfaults

[Anonymous Monk]

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

$ perl Build.PL --install_base=..\snacks
...
$ build install
Building Data-Dump-Streamer
Files found in blib\arch: installing files in blib\lib into architectu
+re dependent library tree
Installing ..\snacks\lib\perl5\MSWin32-x86-multi-thread\auto\Data\Dump
+\Streamer\Streamer.bs
Installing ..\snacks\lib\perl5\MSWin32-x86-multi-thread\auto\Data\Dump
+\Streamer\Streamer.dll
Installing ..\snacks\lib\perl5\MSWin32-x86-multi-thread\DDS.pm
Installing ..\snacks\lib\perl5\MSWin32-x86-multi-thread\Data\Dump\Stre
+amer.pm
Installing ..\snacks\lib\perl5\MSWin32-x86-multi-thread\Data\Dump\Stre
+amer\_\Printers.pm

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

Re^3: DBD::mysql fail install check (DYLD_LIBRARY_PATH ldd otool install_name_tool VERSIONER_PERL_PREFER_32_BIT .bundle/.dylib/.so

Re^3: DBD::mysql fail install check (crontab debugging troubleshooting DYLD_LIBRARY_PATH ldd otool ...)

[dlamb]

Re: Question 1: I understand that the different perl versions are incompatible. But then why does doing  PERL5LIB='/Users/derek/local/lib/perl5' pnmquant 256 img.pnm segfault (well, I know why, because that PERL5LIB is for 5.14 and pnmquant uses /usr/bin/perl v5.10) but PERL_DL_NONLAZY=1 PERL5LIB='/Users/derek/local/lib/perl5' pnmquant 256 img.pnm produces the correct result without segfaulting? Seems like PERL_DL_NONLAZY is doing something, but I don't understand what, apparently.

The Netpbm scripts (clarification, just in case: Netpbm is not a Perl module) have /usr/bin/perl hard-coded in their #!, so I don't think changing their install location will affect things.