Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) 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
produced the following […]

In a follow-up a Monk stated:

If you're using the (Ubuntu) stock Perl interpreter, you want to install Perl modules through apt-get (or whatever other package tool is en vogue on Ubuntu currently). The package is libwww-mechanize-perl.

Don't install modules into the system Perl. Always use the system package manager. If you want to use cpan to install (more current) versions from CPAN, compile and install your own Perl or use local::lib. Neither is hard.

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 package­manage 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):

PERL5LIB="/opt/cpan-installed/perl/lib/perl5:/opt/cpan-installed/perl/ +module-lib/5.10/arch/i486-linux-gnu-thread-multi:/opt/cpan-installed/ +perl/module-lib/5.10/lib" perl -MExtUtils::Install -e 'printf "%-62s + %s\n", $INC{q|ExtUtils/Install.pm|}, ExtUtils::Install->VERSION' /opt/cpan-installed/perl/lib/perl5/ExtUtils/Install.pm 1.52
PERL5LIB="" perl -MExtUtils::Install -e 'printf "%-62s %s\n", $INC{q| +ExtUtils/Install.pm|},ExtUtils::Install->VERSION' /usr/share/perl/5.10/ExtUtils/Install.pm 1.44

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:

sudo PERL5LIB="/opt/cpan-installed/perl/lib/perl5:/opt/cpan-installed +/perl/module-lib/5.10/arch/i486-linux-gnu-thread-multi:/opt/cpan-inst +alled/perl/module-lib/5.10/lib" \ make pure_site_install
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
    'make_install_make_command' => q[sudo PERL5LIB="${PERL5LIB}" make] (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:     $conf->set_program( sudo => '/usr/bin/sudo PERL5LIB="${PERL5LIB}" ' ); 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:

  1. $ cpanp
  2. CPAN Terminal> s reconfigure
I choose 8 from the selection menu that appears:

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.


In reply to Distro Pkg-Managed, broken Install.pm, sudo clears $PERL5LIB by Intrepid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (6)
As of 2024-03-29 10:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found