Bob McGowan wrote:
> On 06/16/2010 01:54 PM, Martin J. Evans wrote:
>> On 16/06/2010 20:22, Bob McGowan wrote:
>>> On 06/16/2010 05:14 AM, Martin Evans wrote:
>>>   
>>>> Benjamin Mark wrote:
>>>>     
>>>>> "Bob McGowan"<bob_mcgo...@symantec.com>  wrote in message
>>>>> news:4c110b04.60...@symantec.com...
>>>>>       
>>>>>> On 06/09/2010 08:43 AM, Benjamin Mark wrote:
>>>>>>         
>>>>>>> Hello,
>>>>>>>
>>>>>>> I wan't to install the DBD::Oracle package on Ubuntu 8.04 LTS.
>>>>>>> I've installed a Oracle 10gR2 database (not the client) which is
>>>>>>> running
>>>>>>> well.
>>>>>>>
>>>>>>> Everytime I wan't to install the package I got the message:
>>>>>>>
>>>>>>> #####################################################################
>>>>>>> Removing previously used
>>>>>>> /home/administrator/.cpan/build/DBD-Oracle-1.24
>>>>>>>            
>>> <<--Deleted on purpose-->>
>>>
>>>   
>>>>> thx for your answer. Yes the oracle 10g is on the same machine.
>>>>> But for any reason the installer/compiler can't see the right libraries
>>>>> packages but the path is definetivly the right one.
>>>>> In the maintime I've succeeded to the tell the user the right
>>>>> environment
>>>>> variables but the installer still has problems.
>>>>>
>>>>> #####################################################################
>>>>>    CPAN.pm: Going to build P/PY/PYTHIAN/DBD-Oracle-1.24b.tar.gz
>>>>>
>>>>> Argument "6.30_01" isn't numeric in subroutine entry at Makefile.PL
>>>>> line 10
>>>>>          main::BEGIN() called at
>>>>> /usr/share/perl/5.8/ExtUtils/MakeMaker.pm
>>>>> line 10
>>>>>          eval {...} called at
>>>>> /usr/share/perl/5.8/ExtUtils/MakeMaker.pm line
>>>>> 10
>>>>> Using DBI 1.601 (for perl 5.008008 on i486-linux-gnu-thread-multi)
>>>>> installed
>>>>> in /usr/lib/perl5/auto/DBI/
>>>>> Argument "6.30_01" isn't numeric in numeric ge (>=) at Makefile.PL
>>>>> line 61.
>>>>>
>>>>> Configuring DBD::Oracle for perl 5.008008 on linux
>>>>> (i486-linux-gnu-thread-multi)
>>>>>
>>>>> Remember to actually *READ* the README file! Especially if you have any
>>>>> problems.
>>>>>
>>>>>    The ORACLE_HOME environment variable value
>>>>> (/home/oracle/product/10gR2) is
>>>>> not valid.
>>>>>        
>>> <<--Deleted on purpose-->>
>>>
>>>   
>>>>>        
>>>> I find the easiest way to get DBD::Oracle working is this:
>>>>
>>>> o get Oracle InstantClient for your platform
>>>> o unzip it somewhere (perhaps inside /home/oracle on your machine)
>>>> o make sure all dirs and files in the instantclient dir are readable by
>>>> the users and installers
>>>> o set LD_LIBRARY_PATH to point at instant client dir
>>>>    e.g., export LD_LIBRARY_PATH=/home/oracle/instantclient_11_1/
>>>> o download DBD::Oracle, untar it and change into created dir
>>>> o run perl Makefile.PL, make, make test sudo make install
>>>>
>>>> Hope this helps.
>>>>
>>>> Martin
>>>>      
>>> Martin, the point of the OP is that the standard sequence you describe
>>> isn't working for him.
>>>
>>> Ben, there are several things in the earlier part of the error messages
>>> that don't make sense.  For example, 'Argument "6.30_01" isn't numeric
>>> ...' shouldn't be happening, so far as I can tell.  The underscore is a
>>> "readability" thing, for humans, and Perl strips it (whether the string
>>> is quoted or not), so that "6.30_01" ends up being "6.3001".  I tested
>>> this in debug mode and can state this with 100% confidence (besides, the
>>> docs say the same thing ;).
>>>
>>>    
>> With great respect I don't agree with this. If you have E:M 6.30_01 you
>> do get this warning - it is scattered all over the smoke testers
>> results. I don't think this has anything at all to do with the failure
>> to build and that is why I ignored it.
> 
> Perhaps I'm not seeing/noticing something that you are?  All I see in
> the error message provided by the OP is "6.30_01", there is no "E:M"
> mentioned.


Argument "6.30_01" isn't numeric in subroutine entry at Makefile.PL line
10  main::BEGIN() called at /usr/share/perl/5.8/ExtUtils/MakeMaker.pm
line 10 eval {...} called at /usr/share/perl/5.8/ExtUtils/MakeMaker.pm
line 10

Line 10 of Makefile.PL is:

use ExtUtils::MakeMaker 5.16, qw(&WriteMakefile $Verbose);

and the Ben's version of E::M is 6.30_01 (note the _01) usually causes
this. However, I must admit it usually causes it at line 61 like this:

Argument "6.56_01" isn't numeric in numeric ge (>=) at Makefile.PL line
61 which is:

if ($ExtUtils::MakeMaker::VERSION >= 5.43) {

and now that I look at it again I am surprised it barfed at line 10. I
saw the E::M version warning and ignored it out of hand assuming it was
the usual one from line 61. I'd guess this may be to do with his older
Perl 5.8.8.

> What is this and where does it come from?  I agree, it would certainly
> change the tests, if present, I'm just not seeing it.
> 
> And I goofed badly in my comment to you.  The OP is following the
> "standard procedure" for building *without* the Instantclient.

I realise that but given that no one had diagnosed his problem I
suggested using Instant Client which in my opinion is much easier to use
and has less pitfalls with file permissions, ORACLE_HOME etc.

>>> In my experience, things like this are often the result of "cascading"
>>> errors, that is to say, something is wrong, somewhere else, that causes
>>> these to happen.
>>>
>>> So, look at your ORACLE_HOME value.  The message above says it is not
>>> valid.  Fix that first, then maybe the other issues will go away.
>>>
>>>    
>> Here again, we have no evidence that the method I provided fails when
>> ORACLE_HOME is not set as ORACLE_HOME does not NEED to be set when using
>> instant client.
> 
> Agreed, ORACLE_HOME is not relevant in the Instantclient case.
> 
> But it is for the case where you are *not* using Instantclient.  But
> more may be missing, see below ...
> 
>>> Some thoughts on why it might not be valid:
>>>
>>> 1.  The directory permissions and/or file permissions don't allow the
>>> user doing the build to read anything.  So, you might want to run a
>>> 'chmod' on directories and files.  I suggest using 'find' and 'xargs' so
>>> you can separate directories from files.  From the top level of the
>>> *Oracle install*, as root or the user who actually owns the Oracle files
>>> and directories (for my install, that was 'oracle'):
>>>
>>>    find . -type f | xargs chmod go+r # add read for all to all files.
>>>    find . -type d | xargs chmod go+rx # add read/search for all on all
>>>                                       # directories
>>>

This of course is a possible reason but this is exactly why I suggest
InstantClient as you can unzip it anywhere without fiddling with your
main Oracle installation and risking breaking it. Plus you can install
it as any user in your home directory if you like.

>>> 2.  The path is in fact not correct.  This could be due to a directory
>>> name having white space in it, or to having a value that is too short or
>>> too long (too few or too many directory levels).
>>>
>>> Doing an 'ls $ORACLE_HOME', you should see names like:  bin css dbs demo
>>> jdk network precomp ...
>>>
>>> If you don't see them, your ORACLE_HOME is not set correctly.  Figure
>>> out where the above named items are and 'pwd' gives to correct value
>>> to use.

True but the original report said:

Your LD_LIBRARY_PATH env var is set to ''
The ORACLE_HOME environment variable is not set and I couldn't guess

and Ben said:

"The ORACLE_HOME and LD_LIBRARY_PATH is set for user administrator (root
priviliges) and oracle user."

Much more likely is ORACLE_HOME is set but not exported:

$ ORACLE_HOME=/home/martin/instantclient_11_1/
$ ls $ORACLE_HOME
adrci         genezi      libclntsh.so       libnnz11.so
libociei.so      libsqlplusic.so  ojdbc5.jar  sdk      SQLPLUS_README
BASIC_README  glogin.sql  libclntsh.so.11.1  libocci.so.11.1
libocijdbc11.so  libsqlplus.so    ojdbc6.jar  sqlplus

$ perl -le 'print "ORACLE_HOME=$ENV{ORACLE_HOME}\n";'
ORACLE_HOME=

>>> 3.  Finally, just to be sure, your 'LD_LIBRARY_PATH' would be
>>> "$ORACLE_HOME/lib".
>>>
>>> But, it's so much easier to do this if you'd just use Instantclient, as
>>> Martin and others have suggested.  There are specific instructions in
>>> the README* files on how to set up the environment variables to take
>>> advantage of this package.
>>>


>> The OP admitted he had not installed an Oracle client which is why I
>> suggested installing InstantClient - I've done this loads of times on
>> many machines and know it works. Plus the OP is installing from the cpan
>> shell which introduces a load of differences. I don't like that output
>> saying ORACLE_HOME is not set as in fact it does not NEED to be set for
>> instant client. Admittedly, there is something strange going on with the
>> OP's output but we don't really know what was installed and available.
>> Install Instant Client and re-run and if it fails report the problems
>> and we'll take it from there.
> 
> I'm sorry, I had missed making the connection that the user had only
> installed the server, even though it is very clearly stated.
> 
> I've used the Instantclient since it first became available.  And, when
> it wasn't, I would install both parts so I'd have "my own" setup for
> testing.
> 
> So it's very likely there's not enough of Oracle available in the OP's
> setup to build properly.

quite likely or ORACLE_HOME is not exported.

It is worth remembering running with -d argument to Makefile.PL gives
more info:

perl Makefile.PL -d

however, I think Ben was installing via the CPAN shell.

> Whatever the cause, since I've never seen the problem and can't
> duplicate it, I was using what experience I have to try and guide my
> suggestions.
> 
> The fact that the error does say the OP's ORACLE_HOME is invalid,
> indicates he hasn't gotten the environment configured correctly, and I
> would suggest fixing the "highest" level errors first, just in case they
> are contributing in some way.  Whether they are or not, they muddy the
> waters and make it harder, I think, to troubleshoot the problem.
> 
> And, ultimately, if he'd follow the suggestion we both made and use the
> Instantclient, things would probably be easier all around.
> 
>> I am constantly suprised at the number of these posts as I've never had
>> any real problems (over years and many oracle versions and on many
>> platforms) - perhaps someone ought to start compiling a list of these
>> issues to feedback to John.
>>
>> Martin
>>
> 
> 

I hope you get it sorted out Ben.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Reply via email to