This content has been marked as final. Show 4 replies
If you are shipping the instant client with your application, why don't you just have your application set the LD_LIBRARY_PATH if it needs it?
That's the approach currently under consideration.
I'm more concerned about the sort of issues described at
[Oracle Solaris blog: avoiding the LD_LIBRARY_PATH|[http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the]
[Why LD_LIBRARY_PATH is bad|http://xahlee.org/UnixResource_dir/_/ldpath.html]
There's not a lot of guidance in the Instant Client documentation. The regular Oracle Client seems to bypass this problem generally by defining ORACLE_HOME and the like plus including $ORACLE_HOME/bin in the PATH.
Edited by: biberdorf on Feb 8, 2012 1:08 PM
Edited by: biberdorf on Feb 8, 2012 1:09 PM
While I agree that globally setting LD_LIBRARY_PATH is a dangerous thing (and even carelessly modifying /etc/ld.so.conf can be a problem), I think that it is no problem in the case of Oracle Instant Client unless you have several Oracle installations on one machine because there is hardly any danger of library name collision.
That said, I guess that you cannot guarantee that your customers don't have other Oracle software installed on the machine :^)
I see two good ways for you:
1) If Instant Client is always installed in the same path (e.g. if you include it in a non-relocatable RPM), you can link your executable with -rpath <path to Instant Client>.
2) If that won't work (if the user can select the installation path), start your executable from a wrapper script that sets LD_LIBRARY_PATH only in the environment of the executable.
Thanks for that additional information. After talking with our build team, I suspect that the second option will be our solution.
What we want to avoid is doing anything that interferes with any other Oracle software that might be on the system. We'd really like to keep this local to our application.