Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior

by sirhalos (Sexton)
on Sep 12, 2017 at 22:55 UTC ( #1199241=perlquestion: print w/replies, xml ) Need Help??
sirhalos has asked for the wisdom of the Perl Monks concerning the following question:

Servers are running Solaris 10 running Perl 5.8.4 32-bit.

The database department has several versions of Oracle installed from version 10 ~ 12 both 64-bit and 32-bit.

To get around that they have a bourne shell script that when you give it a SID it looks at a file that will source the proper ORACLE_HOME, LD_LIBRARY_PATH, SQL_PRODDIR, FORM_PRODDIR, ORACLE_SID, etc. to your shell's setopt. When I look at how the script changed things it points to Oracle's 64-bit library directory.

My department maintains a few thousand scripts still using Solaris 10 with a few hundred crons. We have 3 new Linux VM's which I installed perlbrew on in our departments directory to migrate to. However, we really need to have a newer version of Perl running on Solaris too to help this migration. I can compile a newer version of Perl for Solaris in our department directory but I have run into problems.

Problem 1: I haven't been about to figure out how they managed to run Perl 5.8.4 32-bit pointing to the Oracle 64-bit library directory. When I compile Solaris myself and then install DBI, then DBD it will fail without pointing LD_LIBRARY to Oracles 32-bit directory.

Problem 2: They are roughly 80 employees using one of these Solaris servers (filesystems all linked together). I do not have root, IT no longer supports the servers that they think no one uses anymore. Therefore, I cannot add a new LD_LIBRARY_PATH to each employees .profile.

Problem 3: I cannot update a few thousand scripts to add a BEGIN block with $ENV{LD_LIBRARY_PATH} to get around their script and mimic it, since it needs the SID, and I won't know the SID, unless I run a web service...

Therefore, I really need help getting this to work. I need to just know how I'm compiling either Solaris incorrectly (the documentation isn't well), or DBD::Oracle. There must be something in there where it is allowing 32-bit and 64-bit libraries to co-exist, it is the only thing I can figure out.

This was the last compile style I tried to accept this mix/match. sh Configure -des -Dprefix=/support/d63/perl5-solaris -D_LARGEFILE64_SOURCE

Is there anyway I can figure out based on the previous Perl install?

I do not have root. IT does not support these servers that run the entire frontend of the company. I will be leaving the department soon and I really want to leave a good Perl setup behind, it is very important to me (I was the main/only Perl programmer for the entire operation). I have spent the past few years modernizing the Perl and moved a lot to Linux, but it hasn't put a dent into this operation. I have spent the last 2 weeks writing Perl documentation from Modern Perl, to Moose, and more. This is the only thing left I really want to get to work. This department is in grave danger with their current setup and I'm trying to save them before they don't have a department and a newer one comes along with something else. I just want to leave them with the newest Perl, working with DBI and DBD::Oracle the way it already does so they can use my documentation to do more Modern things, move off Solaris to Linux and so forth to modernize things when I'm gone to keep the department running for years to come.

  • Comment on Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior

Replies are listed 'Best First'.
Re: Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior
by marto (Bishop) on Sep 13, 2017 at 09:30 UTC

    I sympathize, having worked my day job mainly on a Solaris/Oracle system for many years. First some comments:

    With respect , this isn't really your problem.

    From what you describe:

    • "IT does not support these servers that run the entire frontend of the company."
    • "I will be leaving the department soon" .... "I was the main/only Perl programmer for the entire operation".
    • "This department is in grave danger with their current setup and I'm trying to save them before they don't have a department and a newer one comes along with something else"

    This reeks or management/business decision issues, which the company (not you specifically) should address. It's clear to anyone reading this that you have good intentions, the company should support and enable you to fix their problems, either by giving you the access you need, or at least having someone properly support these production systems.

    Each version of Oracle ships with it's own version of perl, hidden in the train wreck of the application install that is Oracle, are you confusing the system perl with this, or are you getting confused by the number of different builds/DBD::Oracle builds?

    My first recommendation would be to install your own modern perl somewhere on the system, and once you're happy you have all the options right. Our stack was somewhat similar, except that I setup a modern build environment, as what ships with Solaris is so old.

    "Is there anyway I can figure out based on the previous Perl install?"

    You likely know that perl -V will provide compile time information.

    My suggestion is that you take a step back and start from scratch. Read INSTALL and README.solaris (patch inbound, some of those links are long dead), as well as the DBD::Oracle documentation and hints.

    If you still have troubles post a concrete example of what you tried, how it failed and details of your setup (compiler etc).

      I just wanted to thank you. I was able to get this to work using your suggestion. Hopefully this will help this department and keep them in business; tomorrow is my last day before I move on. Thank you so very much.

        You're welcome, I'm glad this worked out. Good luck with your move.

      The Perl that was in the #!shebang line was a Perl they installed back in around 2004 located in /usr/local/perl5, so not the one that comes with Oracle.

      We do have a department directory, which I have what we call 'admin' permissions on, so I can do anything I want in that directory and in that directory alone, hence why I can compile Perl in that directory.

      Yes, I know it is a management problem, the company is over 100 years old, new management is only thinking about the front end, and making new and exciting stuff to sell to customers. They don't realize the whole company runs on old stuff that needs replaced too (content gathering, selection, ingestion). Face lifts don't fix the backend.

        "We do have a department directory, which I have what we call 'admin' permissions on, so I can do anything I want in that directory and in that directory alone, hence why I can compile Perl in that directory"

        We have a similar setup, this is where I built everything from the ground up, avoiding any Sun/Oracle stupidity. With some effort it all works, DBD::Oracle now running against Oracle 12c, various other versions before that.

        "Face lifts don't fix the backend."

        This is the real difficult problem which someone (perhaps not you) should address with urgency.

Re: Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior
by Anonymous Monk on Sep 13, 2017 at 01:09 UTC

    Hi,

    Read my directly linked links below for ideas, an overview, then pick a thing to try ... all the external links I link in the links below are worth reading

    Problem 1: I haven't been about to figure out how they managed to run Perl 5.8.4 32-bit pointing to the Oracle 64-bit library directory. When I compile Solaris myself and then install DBI, then DBD it will fail without pointing LD_LIBRARY to Oracles 32-bit directory.

    Its simple, they didn't do that :) they must not depend on LD_LIBRARY for that version of DBD/Oracle.so, and the correct path is baked in (check with ldd -V ) or they linked against static "liboracle" (or instaclient whatever the actual detail) which doesn't care if LD_LIBRARY_PATH points to some 64bitness version, cause its not gonna try and load it anyway

    Problem 2: They are roughly 80 employees using one of these Solaris servers (filesystems all linked together). I do not have root, IT no longer supports the servers that they think no one uses anymore. Therefore, I cannot add a new LD_LIBRARY_PATH to each employees .profile.

    Then "Bake" in the correct path into Oracle.so?

    Or link against static version of liboracle not depend on "liboracle.so"?

    Or set the path from a module everybody depends on (warnings.pm, strict.pm, or a custom module already found in perlrun#PERL5OPT , PERLLIB

    or set inside sitecustomize.pl (see under perlrun#* f* )

    Problem 3: I cannot update a few thousand scripts to add a BEGIN block with $ENV{LD_LIBRARY_PATH} to get around their script and mimic it, since it needs the SID, and I won't know the SID, unless I run a web service...

    bake...

    Therefore, I really need help getting this to work. I need to just know how I'm compiling either Solaris incorrectly (the documentation isn't well), or DBD::Oracle. There must be something in there where it is allowing 32-bit and 64-bit libraries to co-exist, it is the only thing I can figure out.

    What do you get when you run ldd -v libclntsh.so.11.1 or ldd -v Oracle.so?

    More of the same references below (baking is install_name_tool ...)

    Re^3: DBD::mysql fail install check (DYLD_LIBRARY_PATH ldd otool install_name_tool VERSIONER_PERL_PREFER_32_BIT .bundle/.dylib/.so

    Right, in that case, ldd blib/...so, then adjust your LD_LIBRARY_PATH or use install_name_tool or add -R/instead/of/LD_LIBRARY_PATH to LIBS/CCFLAGS

    Re^3: DBD::Oracle charsetid symbol error,

    Re^7: Installing Glib on Debian,

      It looks like you were correct!

      libclntsh.so.10.1 => /vol/ora_client/product/10.2.0.2/lib32/libclntsh.so.10.1

      libnnz10.so => /vol/ora_client/product/10.2.0.2/lib32/libnnz10.so

      So how do I 'bake it' in?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1199241]
Approved by jonadab
Front-paged by Corion
help
Chatterbox?
[1nickt]: Discipulus I was sleeping in :-) It's a Holyday here. No work today. Just eating. Enjoy your day everymonk!

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (9)
As of 2017-11-23 14:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:













    Results (336 votes). Check out past polls.

    Notices?