Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Installing WWW::Mechanize on AIX - The battle

by perl_monster (Novice)
on Jul 06, 2012 at 16:15 UTC ( #980314=perlquestion: print w/ replies, xml ) Need Help??
perl_monster has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks
I am trying to install WWW::Mechanize on an AIX 5.3 machine but I am getting a plethora of errors. I am trying below coammand

 cpan> install WWW::Mechanize

I get errors like.
1. ExtUtils::MakeMaker version 6.3 required--this is only version 6.17 at Makefile.PL line 7.
2. LD_RUN_PATH="" ld -bhalt:4 -bM:SRE -bI:/u01/oracle/product/10.2.0/perl/lib/5.8.3/aix-thread-multi/CORE/perl.exp -bE:Bzip2.exp -bnoentry -lpthreads -lc_r -L/usr/local/lib blocksort.o huffman.o crctable.o randtable.o compress.o decompress.o bzlib.o Bzip2.o -o blib/arch/auto/Compress/Raw/Bzip2/Bzip2.so ld: 0711-738 ERROR: Input file blocksort.o:
XCOFF32 object files are not allowed in 64-bit mode.

Error 1. is more understandable but I am not too sure about error 2. Would appreciate tips on rectifying these.

Comment on Installing WWW::Mechanize on AIX - The battle
Download Code
Re: Installing WWW::Mechanize on AIX - The battle
by Tanktalus (Canon) on Jul 06, 2012 at 16:59 UTC

    Perl 5.8.3 is severely old. The system perl (/usr/bin/perl) is probably newer than that. (5.8.8 IIRC, but I don't have an AIX 5 box anymore to check with.) Do you have to use the perl that is inside Oracle for this? I would suggest installing your own perl and using that. I've been regularly building 5.16.0 and 5.17.* ("blead") on AIX 6 and 7 (7 has a minor issue, but I think IBM has fixed it, just waiting to get the fix applied to the system to be sure). Tux has been building on 5.2 and 5.3 fairly regularly as well. This would resolve your first issue. Failing that, you may be able to "install ExtUtils::MakeMaker" - I'm not sure if that will eventually drag in a newer version of perl and then you're back to installing a private perl again anyway as I wouldn't suggest upgrading the perl included with Oracle.

    It also looks like you're mixing 32-bit and 64-bit objects. Or at least 32-bit objects when perl might be compiled for 64-bit (which would make sense since the perl that comes with AIX is 32-bit). Again, a recommendation for a private perl: I've had this issue when compiling against the system perl, but never with a private perl.

    I'd also be tempted to ask Oracle if they support you installing additional modules to their private perl. I'd somewhat expect a response like "Um, er... what?" which might also give you impetus to use your own perl. I do expect, however, that there should be no problem connecting to Oracle from your own private perl. You shouldn't require Oracle's perl to connect to their db.

      Yes Perl 5.3 is severely old, and yes it is Oracle's private perl in AIX. I am sure they won't support external PMs (except DBD and DBI, or maybe not). I was able to successfully install a couple of external modules like XML::XPath and Net::Stomp to Oracle perl but WWW::Mechanize seems to have a whole lot of dependencies. I can use AIX's perl installation to get Mechanize in, but the problem is the job scheduler we use, uses Perl profile set for Oracle Perl only, so in order to be able to run a program using AIX perl we will end up creating a new profile.

        5.8.3, not 5.3 :-) I'm guessing it already comes with DBI and DBD::Oracle.

        Now you're running into a few other issues that take a bit more to resolve. Again, I'll reiterate: install a private perl. And then we can more or less resolve the rest of the issues.

        Let's say you install perl 5.16.0. Depending on how your environment is set by the job scheduler, different solutions may present themselves. If, for example, it simply puts Oracle's perl first in the PATH, you can just put your first line to be:

        #!/opt/myperl/5.16.0/bin/perl
        and everything is fine after that. However, if your code is actually being run directly by a hardcoded-in-the-scheduler perl, that is it's running /u01/oracle/product/10.2.0/perl/bin/perl $yourscript directly, it's a bit more convoluted. My suggestion would be to write a wrapper (in perl 5.8.3 syntax). Roughly something like this:
        #! perl # delete $ENV{...} to clean up the environment if needed exec {$0} "$0-wrapped", @ARGV;
        And then have a -wrapped version of the file with your real code in it that starts with the appropriate line above in it. This will have the job scheduler launching the Oracle perl which then reads this file, and it will then tell the kernel (AIX) to execute another program in its place. The kernel will read the magic number from the new program ("#!") and interpret it as a script that needs interpretation, read the rest of the line for the interpreter, and then run that. So it's a bit of an annoyance, but it should all run quick enough not to be noticed.

        And, as a bonus, you'll be able to use the new features in newer perls. Like 5.8.8. :-P

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://980314]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (6)
As of 2014-12-27 23:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (177 votes), past polls