We are migration one of our product.
In the process, the old build server that we used is of sun studio 8 where the c++ version was 5.5. The new build server that we have got now is sun studio 11(old version is not available in the market) and c++ version is 5.8.
In our project the .so files generated using 5.8 are not working in the production environment where as the the .so files generated with 5.5 version are working in the same environment.
If anyone is having the idea please help us in resolving this issue.
I can't tell what you tried or what the result was. For example, did you do this:
1. Create .so files using the old compiler. Example
CCold -G -o libA.so ...
2. Create a program (a.out) using the new compiler, and link to those .so files. Example
CCnew *.o -L/path/to/libA -lA ... -R /path/to/libA
If so, that should just work. You do need a -L option pointing to libA.so so the linker can find it at link time, and also a -R option so the library can be found at run time.
I don't understand the comment "No error, they are not coming up." ("Not coming up" is not a helpful description.)
If there is no error message, how can you tell that something is wrong?
we have compiled and created .o,.so files saparetely on two machines ....
ok... I would like to give more details
Machine A,B are Build servers,Machine C is Production Server
I have a machines with
Machine A) Operating System:SunOs 5.8 Generic_117350-45 sun4u sparc SUNW,Ultra-80(solaris 5.8)
CC Compiler:CC: WorkShop Compilers 4.2 16 Jun 1998 C++ 4.2 patch 104631-07
we have compiled C++ code, generated .so files are working fine on the Machine C
Machine C)Operating System:5.10 Generic_147440-03 sun4v sparc sun4v(Solaris 5.10)
Machine B) Operating System:5.8 Generic_Virtual sun4v sparc sun4v
CC Compiler:CC:CC: Sun C++ 5.8 2005/10/13
we have compiled C++ code, generated .so files are not working fine on the Machine C
Machine C) Operating System:5.10 Generic_147440-03 sun4v sparc sun4v(Solaris 5.10)
Generated .so files of C++ code on Machine A, Machine B(configurations mentioned in Thread),when copied to Machine C have to start the application, when a command is issued on command line of Machine C.
1).so's generated on Machine A are able to start the application on Machine C
2).so's generated on Machine B are unable to start The application on Machine C
We have run the same C++ code on Machine A and Machine B, With The same make files, but on Machine A we have used Make and on Machine B we have used gmake.
so any compilation options for compiler on Machine B to generated the code works on Machine C.
What are all the other factors matters for .so's of Machine B not working fine on Machine C
1) Any run time utilities of OS
2)compiler versions or Libraries or Patches etc.
Any solution to the problem is helpful and appreciable. Thanks in advance.
You can't run a shared library (.so) as an application from a command line. I assume you are running some program that links to, or uses dlopen() to open, the shared library.
If you don't get an error message when you try to start the program, my guess is that the program uses dlopen() to access the shared library, and does not report error conditions. If I am correct, run the program under the debugger (dbx), and look for the value returned from dlopen. If a return value is null (0), dlopen ran into some sort of error. You can't tell directly what the problem was, but you can run dlerror() to get a message describing the error.
If you have the option of modifying the program that opens the shared libraries, I would add error-checking code to report the problem. For example, if the code looks like this: