This content has been marked as final. Show 13 replies
Cannot determine all dependent dynamic libraries for /proc/self/exe
Unable to find dynamic library libocr10.so in search paths
RPATH = /ade/aime1_build2101/oracle/has/lib/:/ade/aime1_build2101/oracle/lib/:/ade/aime1_build2101/oracle/has/lib/:
LD_LIBRARY_PATH is not set!
The default library directories are /lib and /usr/lib
Unable to find dynamic library libocrb10.so in search paths
Unable to find dynamic library libocrutl10.so in search paths
Unable to find dynamic library libocrutl10.so in search paths
Thanks Brian, Fran, Nicolas
On a new machine which just got its OS (solaris/AIX) installed, whenever I do a Binary only installation of Oracle RDBMS, I usually test the installation using
and I should get a
sqlplus / as sysdba
Will sqlplus binary work without setting LD_LIBRARY_PATH? I don't remember setting LD_LIBRARY_PATH either manually or sourcing profile file when I do the testing like above .
Connected to an idle instance.
T.Boyd wrote:The kernel provides a number of call and service interfaces. So too does runtime environments used by C/C++ and other languages. These are typically implemented as shared libraries (aka DLLs in Windows).
LD_LIBRARY_PATH is used when linking modules & not during program execution
So, does this mean I don't have to set LD_LIBRARY_PATH for the above test scenario ? I don't have a RDBMS binary only machine now. Otherwise I could have tested it
When app code is executed, and such an external call is made, the kernel needs to have that shared library at hand to execute the machine code (in that library) for that call.
App code can use 2 methods for dealing with its external calls.
It can be statically coded. This means a "hard" reference in the app code to the function or procedure in the shared lib. At compile time, the executable is build with this hard reference - telling the kernel that when the executable is loaded, it will be making external calls to the following shared libs. The kernel needs to either have these shared libs already loaded into memory and ready for use, or it needs to find the shared lib on disk and load it into memory.
It can be dynamically coded. This is a bit more complex on the app source code side as you need to manually code the loading of the shared lib, determine the address of the external function/procedure you want to call in that library, and then use that address in your code to make your external calls. This code is compiled without a shared lib reference. The kernel does not need to load the shared lib when it loads that app executable - the app will load that shared lib itself.
The advantage of the 2nd method is that your app will still be loaded and executed, irrespective of whether that shared library is available or not. When your app code makes the load shared lib call and it does not exist, that call will fail. If your app is statically linked, your app will fail to execute at all - as the kernel needs to load the shared lib with your app and if it cannot find and load the shared, it also cannot load your executable.
So with the 2nd method you can code an app that supports Oracle, mySQL and Sybase. And this app can run on an Oracle system despite the fact as mySQL and Sybase shared libs are missing. So depending on how your app is configured to run, you only load the client drivers (shared libs) needed at the time and nothing else. If the app was compiled with static references, all 3 sets of database client shared libs had to be available for your app to be loaded.
So this is basically the difference between static shared lib usage and dynamic shared lib usage by executables. Both methods have their pros and cons.
The LD_LIBRARY_PATH variable fits into this as the means to find and resolve the shared lib reference for loading of shared libraries. The load library call (whether called statically by the kernel when loading your executable, or called dynamically from within your loaded executable) needs to find the relevant shared lib on disk. And this environment variable determines where to look on disk for the physical library module to load.
Will sqlplus binary work without setting LD_LIBRARY_PATH?
To invoke sqlplus , LD_LIBRARY_PATH does not have to be set . Tested in AIX. I am sure it is the same in Solaris
I have the following variables set
Then I unset the LD_LIBRARY_PATH variable
ORACLE_BASE=/optware/oracle ORACLE_HOME=/optware/oracle/11g/TST/db ORACLE_SID=orcl PATH=/optware/oracle/11g/TST/db/bin:/optware/oracle/11g/TST/db/PATCH/OPatch:/optware/oracle/11g/TST/db/bin:/opt/SUNWspro/bin:/optware/oracle/O
$ echo $LD_LIBRARY_PATH /optware/oracle/11g/TST/db/lib $ unset LD_LIBRARY_PATH $ echo $LD_LIBRARY_PATH ksh: LD_LIBRARY_PATH: parameter not set $ sqlplus / as sysdba SQL*Plus: Release 18.104.22.168.0 Production on Thu Nov 24 11:19:06 2011 Copyright (c) 1982, 2010, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 22.214.171.124.0 - 64bit Production With the Partitioning option SQL> select name from v$database; NAME --------- ORCL
Whether LD_LIBRARY_PATH is needed or not depends on how the dynamic link loader of the kernel works ito determing where to look for a shared lib.
The Windows dynamic link loader uses the PATH variable (after checking the current dir first). It seems from the test below that Linux needs the LD_LIBRARY_PATH set
There's also a SHLIB_PATH variable used by some Unix flavours.. could be pre-Posix perhaps? Seem to recall that this was used on older 32bit HP-UX kernels.
// current setting /home/billy> echo $LD_LIBRARY_PATH /home/billy/instantclient_10_2:/usr/lib/firefox: // sqlplus loads fine /home/billy> sqlplus SQL*Plus: Release 10.2.0.1.0 - Production on Thu Nov 24 11:38:59 2011 Copyright (c) 1982, 2005, Oracle. All rights reserved. Enter user-name: // unset the environment variable and sqlplus fails to load /home/billy> unset LD_LIBRARY_PATH /home/billy> sqlplus /home/billy/instantclient_10_2/bin/sqlplus: error while loading shared libraries: libsqlplus.so: cannot open shared object file: No such file or directory // this is what the dynamic link loader sees as shared libs that need to // be loaded - and which of these it does not find /home/billy> ldd /home/billy/instantclient_10_2/bin/sqlplus linux-gate.so.1 => (0x00cc1000) libsqlplus.so => not found libclntsh.so.10.1 => not found libnnz10.so => not found libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x006eb000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x005f5000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x001fe000) libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0x00d53000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x009ab000) /lib/ld-linux.so.2 (0x005a8000) // setting the environment and checking what the dynamic link loader sees /home/billy> export LD_LIBRARY_PATH=/home/billy/instantclient_10_2:/usr/lib/firefox: /home/billy> ldd /home/billy/instantclient_10_2/bin/sqlplus linux-gate.so.1 => (0x00bb3000) libsqlplus.so => /home/billy/instantclient_10_2/libsqlplus.so (0x00aa5000) libclntsh.so.10.1 => /home/billy/instantclient_10_2/libclntsh.so.10.1 (0x00fd8000) libnnz10.so => /home/billy/instantclient_10_2/libnnz10.so (0x00778000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x00110000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x001ab000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x00114000) libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0x00bd1000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x001d1000) /lib/ld-linux.so.2 (0x00fba000)
If the ldd command (or similar) is available, it is a good way to check the static link library requirement of an executable and whether the loader can find the required library files on disk.