FAQ
Hello,

I'm sorry to bother you, but I saw Dave Moellenhoff's name and email in
the DBD::Oracle README.help.txt fie for an issue similar to what our
team is seeing when using DBD::Oracle 1.19 that our computing team
installed for our development team. I tried contacting him at the
provided email address with no success (is he the same Dave Moellenhoff
that is the CTO for Salesforce.com?). Our local computing team seems to
not be able to resolve a library path issue we are seeing when using
DBD::Oracle. I think what they're asking us and our customers to do is
a work-around and not the way things should be. Here is the error we
are seeing when we use our "ftrq" tool which uses DBD Oracle:

(SunOS 5.6)

$ ftrq
install_driver(Oracle) failed: Can't load
'/apps/public/lib/perlmodules/5.8.4/sun4-solaris/auto/DBD/Oracle/Oracle.
so' for module DBD::Oracle: ld.so.1: /apps/public/bin/perl: fatal:
libclntsh.so.9.0: open failed: No such file or directory at
/apps/public/perl_5.8.4/lib/5.8.4/sun4-solaris/DynaLoader.pm line 230.
at (eval 3) line 3
Compilation failed in require at (eval 3) line 3.
Perhaps a required shared library or dll isn't installed where expected
at /mot/proj/ddts/admin/lib/Oracle.pm line 137

The work around is to set the following:
LD_LIBRARY_PATH=/apps/vendor/oracle/lib

After setting this the execution is fine. I see this comment in the
README.help.txt file from Mr. Moellenhoff
(http://search.cpan.org/src/PYTHIAN/DBD-Oracle-1.19/README.help.txt):

"Also: Never copy libclntsh.so to a different machine or Oracle version.
If DBD::Oracle was built on a machine with a different path to
libclntsh.so
then you'll need to set an environment variable, typically
LD_LIBRARY_PATH, to include the directory containing libclntsh.so."

Is this related and if so do you have some advice or guidance I can
share with our computing team that can get this resolved so our
customers don't have to set LD_LIBRARY_PATH to use our tool and we don't
have to develop a wrapper for it?

Thanks so much for any assistance you folks can offer.

Kind regards,

Shannon Kerr
iDEN Networks Infrastructure SCM Team
Motorola, Inc.

Search Discussions

  • Kerr Shannon-SKERR1 at Nov 16, 2006 at 3:47 am
    Hello,

    I'm sorry to bother you, but I saw Dave Moellenhoff's name and email in
    the DBD::Oracle README.help.txt fie for an issue similar to what our
    team is seeing when using DBD::Oracle 1.19 that our computing team
    installed for our development team. I tried contacting him at the
    provided email address with no success (is he the same Dave Moellenhoff
    that is the CTO for Salesforce.com?). Our local computing team seems to
    not be able to resolve a library path issue we are seeing when using
    DBD::Oracle. I think what they're asking us and our customers to do is
    a work-around and not the way things should be. Here is the error we
    are seeing when we use our "ftrq" tool which uses DBD Oracle:

    (SunOS 5.6)

    $ ftrq
    install_driver(Oracle) failed: Can't load
    '/apps/public/lib/perlmodules/5.8.4/sun4-solaris/auto/DBD/Oracle/Oracle.
    so' for module DBD::Oracle: ld.so.1: /apps/public/bin/perl: fatal:
    libclntsh.so.9.0: open failed: No such file or directory at
    /apps/public/perl_5.8.4/lib/5.8.4/sun4-solaris/DynaLoader.pm line 230.
    at (eval 3) line 3
    Compilation failed in require at (eval 3) line 3.
    Perhaps a required shared library or dll isn't installed where expected
    at /mot/proj/ddts/admin/lib/Oracle.pm line 137

    The work around is to set the following:
    LD_LIBRARY_PATH=/apps/vendor/oracle/lib

    After setting this the execution is fine. I see this comment in the
    README.help.txt file from Mr. Moellenhoff
    (http://search.cpan.org/src/PYTHIAN/DBD-Oracle-1.19/README.help.txt):

    "Also: Never copy libclntsh.so to a different machine or Oracle version.
    If DBD::Oracle was built on a machine with a different path to
    libclntsh.so
    then you'll need to set an environment variable, typically
    LD_LIBRARY_PATH, to include the directory containing libclntsh.so."

    Is this related and if so do you have some advice or guidance I can
    share with our computing team that can get this resolved so our
    customers don't have to set LD_LIBRARY_PATH to use our tool and we don't
    have to develop a wrapper for it?

    Thanks so much for any assistance you folks can offer.

    Kind regards,

    Shannon Kerr
    iDEN Networks Infrastructure SCM Team
    Motorola, Inc.
  • John D Groenveld at Nov 16, 2006 at 3:59 pm
    In message <D5B296562067EA4EA74DEA9D1E6237340146EAD5@de01exm70.ds.mot.com>, "Ke
    rr Shannon-SKERR1" writes:
    Is this related and if so do you have some advice or guidance I can
    share with our computing team that can get this resolved so our
    customers don't have to set LD_LIBRARY_PATH to use our tool and we don't
    have to develop a wrapper for it?
    If you don't control where the customer is going to install
    Oracle's client libraries, then its impossible to a priori set the
    runtime link path for DBD::Oracle's Oracle.so.

    With Oracle Instant Client and Solaris 7 and newer, you might be
    able to use $ORIGIN.
    See Dave Barr's "Why LD_LIBRARY_PATH is bad"
    <URL:http://xahlee.org/UnixResource_dir/_/ldpath.html>

    John
    groenveld@acm.org
  • Kerr Shannon-SKERR1 at Nov 16, 2006 at 5:52 pm
    Thanks for the reply. The Oracle client libraries are installed at the
    same location on all of our servers (Solaris 2.6 and 2.8). I believe
    the problem is with the configuration and/or installation procedure and
    that's why the libraries are not found on Solaris 2.6 (and so we set
    LD_LIBRARY_PATH) but are found on Solaris 2.8 as they should be (without
    setting LD_LIBRARY_PATH). The computing team believes they have the
    proper installation, but I don't understand why we have this issue only
    on Solaris 2.6 if the installation is correct.

    ---------------------------
    Is this related and if so do you have some advice or guidance I can
    share with our computing team that can get this resolved so our
    customers don't have to set LD_LIBRARY_PATH to use our tool and we
    don't
    have to develop a wrapper for it?
    If you don't control where the customer is going to install
    Oracle's client libraries, then its impossible to a priori set the
    runtime link path for DBD::Oracle's Oracle.so.
    With Oracle Instant Client and Solaris 7 and newer, you might be
    able to use $ORIGIN.
    See Dave Barr's "Why LD_LIBRARY_PATH is bad"
    <URL:http://xahlee.org/UnixResource_dir/_/ldpath.html>
    John
    groenveld@acm.org
  • John D Groenveld at Nov 16, 2006 at 8:58 pm
    In message <D5B296562067EA4EA74DEA9D1E6237340146EC66@de01exm70.ds.mot.com>, "Ke
    rr Shannon-SKERR1" writes:
    Thanks for the reply. The Oracle client libraries are installed at the
    same location on all of our servers (Solaris 2.6 and 2.8). I believe
    the problem is with the configuration and/or installation procedure and
    that's why the libraries are not found on Solaris 2.6 (and so we set
    LD_LIBRARY_PATH) but are found on Solaris 2.8 as they should be (without
    setting LD_LIBRARY_PATH). The computing team believes they have the
    proper installation, but I don't understand why we have this issue only
    on Solaris 2.6 if the installation is correct.
    Its easy enough to confirm. On your working Solaris 8 host,
    $ env - /usr/bin/ldd /opt/MOTapp/perl-5.8.8/lib/site_perl/5.8.8/sun4-solaris/auto/DBD/Oracle/Oracle.so | grep libclntsh.so
    libclntsh.so.10.1 => /opt/oracle/product/10.1.0/lib/libclntsh.so.10.1

    On your broken Solaris 2.6 host,
    $ env - /usr/bin/ldd /opt/MOTapp/perl-5.8.8/lib/site_perl/5.8.8/sun4-solaris/auto/DBD/Oracle/Oracle.so | grep libclntsh.so
    libclntsh.so.10.1 => (file not found)
    $ ls -l /opt/oracle/product/10.1.0/lib/libclntsh.so.10.1

    I think you'll find that the Oracle libraries are not where they
    should be on your 2.6 host.

    John
    groenveld@acm.org
  • Kerr Shannon-SKERR1 at Nov 16, 2006 at 10:54 pm
    Thanks, for this. It helped to prove that Oracle.so is indeed not able
    to locate libclntsh.so, so now the trick is to help the computing team
    to understand what they did wrong during the implementation of
    DBD::Oracle and what they can do to fix the problem. Any suggestions
    here?

    -Shannon

    -----Original Message-----
    From: John D Groenveld
    Sent: Thursday, November 16, 2006 2:56 PM
    To: Kerr Shannon-SKERR1
    Cc: dbi-users@perl.org
    Subject: Re: DBD Oracle module

    In message
    <D5B296562067EA4EA74DEA9D1E6237340146EC66@de01exm70.ds.mot.com>, "Ke
    rr Shannon-SKERR1" writes:
    Thanks for the reply. The Oracle client libraries are installed at the
    same location on all of our servers (Solaris 2.6 and 2.8). I believe
    the problem is with the configuration and/or installation procedure and
    that's why the libraries are not found on Solaris 2.6 (and so we set
    LD_LIBRARY_PATH) but are found on Solaris 2.8 as they should be (without
    setting LD_LIBRARY_PATH). The computing team believes they have the
    proper installation, but I don't understand why we have this issue only
    on Solaris 2.6 if the installation is correct.
    Its easy enough to confirm. On your working Solaris 8 host,
    $ env - /usr/bin/ldd
    /opt/MOTapp/perl-5.8.8/lib/site_perl/5.8.8/sun4-solaris/auto/DBD/Oracle/
    Oracle.so | grep libclntsh.so
    libclntsh.so.10.1 =>
    /opt/oracle/product/10.1.0/lib/libclntsh.so.10.1

    On your broken Solaris 2.6 host,
    $ env - /usr/bin/ldd
    /opt/MOTapp/perl-5.8.8/lib/site_perl/5.8.8/sun4-solaris/auto/DBD/Oracle/
    Oracle.so | grep libclntsh.so
    libclntsh.so.10.1 => (file not found)
    $ ls -l /opt/oracle/product/10.1.0/lib/libclntsh.so.10.1

    I think you'll find that the Oracle libraries are not where they
    should be on your 2.6 host.

    John
    groenveld@acm.org
  • John Scoles at Nov 20, 2006 at 4:54 pm
    Do you know which Oracle client they are trying to connect with?

    ""Kerr Shannon-SKERR1"" <shannon.kerr@motorola.com> wrote in message
    news:D5B296562067EA4EA74DEA9D1E6237340146EDD5@de01exm70.ds.mot.com...
    Thanks, for this. It helped to prove that Oracle.so is indeed not able
    to locate libclntsh.so, so now the trick is to help the computing team
    to understand what they did wrong during the implementation of
    DBD::Oracle and what they can do to fix the problem. Any suggestions
    here?

    -Shannon

    -----Original Message-----
    From: John D Groenveld
    Sent: Thursday, November 16, 2006 2:56 PM
    To: Kerr Shannon-SKERR1
    Cc: dbi-users@perl.org
    Subject: Re: DBD Oracle module

    In message
    <D5B296562067EA4EA74DEA9D1E6237340146EC66@de01exm70.ds.mot.com>, "Ke
    rr Shannon-SKERR1" writes:
    Thanks for the reply. The Oracle client libraries are installed at the
    same location on all of our servers (Solaris 2.6 and 2.8). I believe
    the problem is with the configuration and/or installation procedure and
    that's why the libraries are not found on Solaris 2.6 (and so we set
    LD_LIBRARY_PATH) but are found on Solaris 2.8 as they should be (without
    setting LD_LIBRARY_PATH). The computing team believes they have the
    proper installation, but I don't understand why we have this issue only
    on Solaris 2.6 if the installation is correct.
    Its easy enough to confirm. On your working Solaris 8 host,
    $ env - /usr/bin/ldd
    /opt/MOTapp/perl-5.8.8/lib/site_perl/5.8.8/sun4-solaris/auto/DBD/Oracle/
    Oracle.so | grep libclntsh.so
    libclntsh.so.10.1 =>
    /opt/oracle/product/10.1.0/lib/libclntsh.so.10.1

    On your broken Solaris 2.6 host,
    $ env - /usr/bin/ldd
    /opt/MOTapp/perl-5.8.8/lib/site_perl/5.8.8/sun4-solaris/auto/DBD/Oracle/
    Oracle.so | grep libclntsh.so
    libclntsh.so.10.1 => (file not found)
    $ ls -l /opt/oracle/product/10.1.0/lib/libclntsh.so.10.1

    I think you'll find that the Oracle libraries are not where they
    should be on your 2.6 host.

    John
    groenveld@acm.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-users @
categoriesperl
postedNov 13, '06 at 5:38p
activeNov 20, '06 at 4:54p
posts7
users3
websitedbi.perl.org

People

Translate

site design / logo © 2022 Grokbase