http://qs321.pair.com?node_id=1199248


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

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,

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

Replies are listed 'Best First'.
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?