Well, I'd suggest you the reading of the following note : *Solaris: Setting LD_LIBRARY_PATH in 10gR1 and higher [ID 271451.1]*+
In brief, that should work until you are using an application which needs it.

LD_LIBRARY_PATH is used when linking modules & not during program execution

Thanks for the correction. I confused dynamic linking with dynamic load libraries. Similar in concept, but different in execution.
http://docs.oracle.com/cd/B28359_01/server.111/b32009/prcmp_cll_int.htm#UNXAR217

Interesting, when searching for 271451.1, ORA-12537 when connecting to 11.1 Database through 11.2 Listener (Solaris) [ID 975596.1] also comes up. Need env variable set when using 11.2 listener for 11.1 db.

T.Boyd wrote: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

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).

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.