At 10:47 AM 4/9/2008, pgodfrin wrote:
This will obviate the need to use LD_LIBRARY_PATH, which has some
controversy surrounding it's use. I also found a strangeness for the
install of DBD. If I remember correctly, the install document states
that LD_LIBRARY_PATH should be set during the module install, which
will link the value of the LD_LIBRARY_PATH . Indeed the value ends up
in the make file (in the EXTRA_LIBS, LD_RUN_PATH and OTHERLDFLAGS
entries), and the library seems to be available as per the ldd
command, yet, without either an LD_LIBRARY_PATH environment variable
or the ld.so.conf.d method, DBD does not run.
Any thoughts?
pg
I've just been through an install of DBD::Oracle on a Solaris 10
machine and this was my experience as well. My needs were
complicated by the fact that I was running it as a CGI script and
thus did not have a way to easily set an environment variable.
If you set LD_LIBRARY_PATH (or maybe LD_RUN_PATH) while doing the
module build, then Oracle.so will be compiled with the paths to the
modules it needs. But at runtime, it will load (on my system)
libclntsh.so.10.1 which it finds in the oracle instant client
directory. But then libclntsh.so.10.1 will want to load libnnz10.so
and will not be able to because libclntsh.so.10.1 was compiled with a
run path of whatever machine the Oracle client was compiled on. So
what I wound up doing was just symlinking libnnz10.so to /usr/lib and
I could then get my script to run without any runtime load paths.
Hope this helps...
Jim McCullars
University of Alabama in Huntsville
