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

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 (Cardinal) 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).	[reply] [d/l]
Re^2: Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior by sirhalos (Sexton) on Sep 14, 2017 at 12:35 UTC
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.	[reply]
Re^3: Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior by marto (Cardinal) on Sep 14, 2017 at 12:42 UTC
You're welcome, I'm glad this worked out. Good luck with your move.	[reply]
Re^2: Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior by sirhalos (Sexton) on Sep 13, 2017 at 11:35 UTC
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.	[reply]
Re^3: Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior by marto (Cardinal) on Sep 13, 2017 at 11:40 UTC
"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.	[reply]
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,	[reply] [d/l]
Re^2: Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior by sirhalos (Sexton) on Sep 13, 2017 at 11:46 UTC
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?	[reply]
Re^3: Difficult compiling newer Perl on Solaris and DBD::Oracle with odd behavior by Anonymous Monk on Feb 13, 2020 at 02:16 UTC
More of the same references below (baking is install_name_tool ...) Or use install_name_tool ... Problems installing DBD::mysql on OS X Snow Leopard, http://search.cpan.org/dist/DBD-mysql/README.OSX/Problems installing DBD::MySQL on OS X...: Apple Support Communities http://probably.co.uk/post/problems-installing-dbdmysql-on-os-x-snow-leopard/ DBD-mysql-4.018-hYHpKY$ otool -D `mdfind libmysqlclient.16.dylib` /usr/local/mysql-5.5.9-osx10.6-x86_64/lib/libmysqlclient.16.dylib: lib +mysqlclient.16.dylib We can fix this with install_name_tool though: DBD-mysql-4.018-hYHpKY$ sudo install_name_tool -id /usr/local/mysql-5. +5.9-osx10.6-x86_64/lib/libmysqlclient.16.dylib /usr/local/mysql-5.5.9-osx10.6-x86_64/lib/libmysqlclient.16.dylib DBD-mysql-4.018-hYHpKY$ otool -D `mdfind libmysqlclient.16.dylib` /usr/local/mysql-5.5.9-osx10.6-x86_64/lib/libmysqlclient.16.dylib: /usr/local/mysql-5.5.9-osx10.6-x86_64/lib/libmysqlclient.16.dylib [download] https://metacpan.org/source/CAPTTOFU/DBD-mysql-4.022/README.OSX -> Problems installing DBD::MySQL on OS X Li� - Apple Community `For Lion, type: sudo install_name_tool -id /usr/local/mysql-5.5.14-osx10.6-x86_64/lib/ +libmysqlclient.18.dylib /usr/local/mysql-5.5.14-osx10.6-x86_64/lib/li +bmysqlclient.18.dylib` [download]	[reply] [d/l] [select]


Your skill will accomplish what the force of many cannot
	PerlMonks