|No such thing as a small change|
combination of multiple installed Perls and some environment variables cause segfaultsby dlamb (Initiate)
|on Apr 06, 2013 at 07:37 UTC||Need Help??|
dlamb has asked for the
wisdom of the Perl Monks concerning the following question:
First (registered) post. This is a bit of a long one--I was thinking things through while typing it up, which I hope helps you.
I have a Mac running 10.6.8. I have the system perl /usr/bin/perl (5.10.0), and also a MacPorts perl /opt/local/bin/perl (5.14.2), the latter is the first in my $PATH. Until recently I had used CPAN to install non-MacPorts modules into the MacPorts tree /opt/local/lib/perl5/site_perl/. That was OK, but I was told that it was a bad idea to have things in the MacPorts tree that MacPorts doesn't know about, so I recently deleted everything there and reinstalled in my home dir /Users/derek/local/lib/perl5. I put export PERL5LIB="/Users/derek/local/lib/perl5" into my ~/.profile, added INSTALL_BASE=/Users/derek/local to the config options in cpan (makepl_arg and similarly for mbuildpl_arg) and I thought all was well. (yes, I'm aware of local::lib, but don't have it installed.)
Now I am checking some code in the PDL test harness, and the code does image format conversion by calling some netpbm programs (in this case, 'pnmquant'). Some of these are Perl scripts themselves. They start with #!/usr/bin/perl. And I am getting some failures that I think I understand and some I don't, so I wanted to get some outside advice at this point. For the rest of this post, please remember that I have now undefined the $PERL5LIB environment variable, for clarity. The test image is named img.pnm
When I run from the command line
If I prepend VERSIONER_PERL_PREFER_32_BIT=no to that line as recommended in this post I get the same dyld error. That post suggested that modules compiled for different perl versions different from the running perl (specifically 32- vs 64-bit) were the culprit. But I don't think that's the case here. I think it's that doing nm ReadKey.bundle |grep _Perl_xs_api on ~/local/lib/...../auto/Term/ReadKey/ReadKey.bundle returns that symbol and doing the same on the 5.10.0 .bundle (in /System/Library/.....etc) does not return that symbol.
If I instead prepend PERL_DL_NONLAZY=1 to the line, then I get no dyld error and the correct output. This may explain why the code in question does not fail when run under make test (which as you know sets that NONLAZY variable), but does when run under perl -Mblib t/testscript.t.
Question 1: Shouldn't PERL_DL_NONLAZY be helpfully causing these sorts of errors, not preventing them like it seems to be doing?
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?
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.Thanks!