|P is for Practical|
Distro Pkg-Managed, broken Install.pm, sudo clears $PERL5LIBby Intrepid (Deacon)
|on Sep 27, 2010 at 18:02 UTC||Need Help??|
Seeing error mentioned with (ExtUtils::MakeMaker) ExtUtils::Install (.pm)
I noticed that this recent Perlmonks node says in part:
I use Ubuntu and typing # cpan WWW::Mechanize
In a follow-up a Monk stated:
My purpose in repeating the advice from node follow-up is to emphasize that I agree this is correct. I run Perl on Ubuntu as well. I agree that one uses APT to packagemanage the system software. I also would add that I use $PERL5LIB in conjunction with a local software tree rooted at /opt which I populate with newer or unprovided CPAN modules built and installed by using manual build-install procedures.
I did as described with the recent release of ExtUtils::MakeMaker and the environmental variable $PERL5LIB puts the location of the newer version (that version newer than the one supplied as part of the distro package installable via APT) in precedence over the older one. Yet, I was bit at make install time with make reporting the following error about line 557 in ExtUtils/Install.pm.
Not a HASH reference at [some path in standard system]/ExtUtils/Install.pm line 557.I think I know how come that happens.
A googlication returned results which indicate that outside the Perlmonks discussions there have been repeatable encounters with this same error.
When trying to install some recent CPAN packages I encountered this failure as well. However, for me this bit in a confusing manner. Some modules from CPAN require the build and installation of many, many prerequisite dependencies from other CPAN packages, and the Text-Pipe and Text-Pipe-HTML packages (Text-Pipe-HTML-1.100880 at this writing) was one of those. Those dependencies installed under cpanplus without a hitch. Why the final objective failed when all the dependencies install is unclear to me at this point. But it is probably not relevent.
Could there be a bug in an older version of EUMM::Install? Why not? Software often has bugs. However, I do not think that is what is biting here. Instead, I think it is a backwards-incompatible change in how a ExtUtils:: routine is being called.
It seems to me that if I generate my Makefile using a different release of EU::MM then I still cannot avoid this show-stopping error on make install. See here for the distinction created by changing the EU::MM found (without deleting any package-managed files from the hard disk, btw):
Can I remind readers of something that seems often forgotten? When the first glance is taken at an install problem that arises from ExtUtils::, the complexity of the actual succession of events during the process is often blurred in one's mind. ExtUtils::MakeMaker is invoked on a file Makefile.PL and a file Makefile is generated as a result. This file has targets and declarative definitions used in stating target recipes (how to "do" the target). The ExtUtils::MakeMaker library provides code that generates make declarations and target recipes. But the ExtUtils:: namespace also provides libraries that supply some callable code (subroutines) which are used by the make target recipes while make causes execution of processes when the user types make install.
That's two really different kinds of things that are contained in the ExtUtils:: namespace that are distinguished from each other not only by level of indirection but by when they are happening. The environment may change between when make code is generated and when the make executable is invoked on a Makefile …you could run make pure_site_install years after the Makefile was generated by MakeMaker.
With the default system installation¹ provided by my GNU/Linux vendor (Ubuntu) present, I cannot avoid having the "apparently defective" code called even when $PERL5LIB is telling make, and thus telling perl (from $PERL5LIB's status as a "mere environmental variable"), that it ought to be looking elsewhere for the newer ExtUtils::Install. That initially confounded me. But I was confounded because I'd started with a naïve idea of what was wrong (that there was just a bug in the older ExtUtils::Install routine being flagged by the exception handling).
The problem really arises from: The make install step is running under sudo!And by default, sudo clears the user's env completely. Thus we can only get the newer ExtUtils::Install at install time (when it is run, under commands spawned by make), by saying:
Once we have installed (to an alternate $PERL5LIB directory path) a current ExtUtils::Install:
I think that you can use o conf init or a manual edit of ~/.cpan/CPAN/MyConfig.pm
(I use cpanplus, not CPAN.pm, but yitzchak pointed out this CPAN.pm config param and I verified that it appears to work well).
Since cpanplus might be used instead (and is, by me), the following fix might be tested for that setup:
Notice that there is a space before the closing quote; by default the cpanplus config item "sudo" was terminated with that space, and I preserved it in case it is meaningful to the operation of cpanplus, or more specifically, to the generated Make file target-making directives that are going to be used at install-time.
To get to the config setting above (understanding that we are already using cpanplus and this is a change to existing settings), I did:
Welcome to the CPANPLUS configuration. Please select which parts you wish to configure Defaults are taken from your current configuration. If you would save now, your settings would be written to: CPANPLUS::Config::User 1> Select Configuration file 2> Setup CLI Programs 3> Setup CPANPLUS Home directory 4> Setup FTP/Email settings 5> Setup basic preferences 6> Setup installer settings 7> Select mirrors 8> Edit configuration file 9> Save & exit 10> Quit without saving
Save & exit (choice 9) and then try installing the failing CPAN package again, YMMV, caveat perl-user.
¹ : installation of Perl and the core modules, that is.
By the way, now that I've shown my solution to get a make install to work, let me add for those with a different focus, that I don't hold the analytical opinion that I or someone else on PMo has yet shown that there is a bug in the older ExtUtils::Install module (version 1.44 on my local system). What can be deduced more plausibly is only that using a newer revision of other ExtUtils:: library code as part of CPAN package installing, is creating calls in Makefile "code" (target-building recipes) that may be syntactically broken for the older Install.pm subroutine. In other words, backward-compatibility was broken.