Q:

wrong soname of shared library loaded at runtime Ubuntu

I'm using eclipse cdt to compile and run C++ application.  
My_main_program needs specifically libjpeg.so.62.  
My Ubuntu system previously have libjpeg.so.9 at /usr/local/lib/. I happened to compiled and run using libjpeg.so.9 before run-time compatibility errors was raised. 
Then I deleted all libjpeg.*  and installed libjpeg.la, libjpeg.so, libjpeg.so.62 and libjpeg.so.62.0.0 from source.  Then I run ldconfig. 
I can build the project.  The problem is the dynamic linker keeps searching for libjpeg.so.9 and throwing 
'error while loading shared libraries: libjpeg.so.9: cannot open shared object file: No such file or directory' 
at run-time.  
This problem is killing me. 
I have checked that the symlink of libjpeg.so is correct. 
Please help! 

A:

I can build the project.  The problem is the dynamic linker keeps searching for libjpeg.so.9 and throwing

'error while loading shared libraries: libjpeg.so.9: ... No such file ...

You need to understand a couple of things:

A shared library may have SONAME dynamic tag (visible with readelf -d foo.so | grep SONAME). 
If an executable is linked against such a library, the SONAME is recorded as a NEEDED dynamic tag (in the executable), regardless of what the library itself is called.  That is, you can name the library foo.so, foo.so.1234, or anything else.  IF the library has SONAME of libbar.so.7, then the executable will require libbar.so.7, no matter what [1]. 

On to your problem.  Your executable fails to load libjpeg.so.9, therefor we conclude that it is being linked (at build time) with a shared library which has SONAME: libjpeg.so.9. 

I deleted all libjpeg.*  and installed libjpeg.so.62

You must not have deleted the libjpeg.so that is used at executable build time (which is somewhere other than /usr/local/lib).  That library still has SONAME: libjpeg.so.9, and is causing you grief. 
You can find out which libraries are being used at link time by passing -Wl,-t flag on the link line. 
[1] Not strictly true: if the executable doesn't need any symbols from foo.so, and if --as-needed linker option is in effect, then NEEDED: libbar.so.7 will not be recorded after all. 
Update:

I have also check ldd executable and it returns libjpeg.so.62 

This means that the executable that you run ldd on is correct, but the executable that actually run is not, and they must be different executables. 
Update 2:

You're right.  ldd executable shows both libjpeg.so.62 and libjpeg.so.9 are included

Actually, no, I wasn't.  But I will be right this time. 
What's happening is that your executable correctly records NEEDED: libjpeg.so.62 (you can verify this with the following command: readelf -d /path/to/exe | grep 'NEEDED.*libjpeg'). 
But you also have some other shared library (one of the ones listed in ldd output), which has not been rebuilt, and still has a dependency on libjpeg.so.9. 
You can find that library by running readelf -d /path/to/libXXX.so | grep 'NEEDED.*libjpeg\.so\.9' on all libraries listed in ldd output. 
Once you find it, you'll have to rebuild it so it also depends on libjpeg.so.62.