While building the whole project, the source files are compiled to object files successfully but when it is creating shared object (.so) files it stops at the below error:The command line as shown lists no files to be linked into xmem.so. Hence the error message.
/opt/solarisstudio12.3/prod/bin/CC -mt -i -library=stlport4 -zdefs -ztext -G -h xmem.so -Lpic/lib/debug/sol32 -L/MyHome/open_source/abc/lib/sol32 -L/MyHome/open_source/mno/lib/sol32 -L/MyHome/open_source/pqr/lib/sol32 -L/MyHome/open_source/xyz/lib/sol32 -g -lc -lCrun -lumem -m32 -o debug/xmem.so
*usage: CC [ options ] files. Use 'CC -flags' for details*
Note:If they are compiled by some other C++ compiler, you will not be able to use the object files in your program.
Some third party open source libraries are being used in the project. Those libraries are not built using Solaris Studio 12.3 compilers.
Tried changing lot of options and re-ordering the switches/options but no luck. But on changing as mentioned below the shared library DID build successfullyA space after -L is optional. The options
- Added space after '-L' option, added '*' at the end of path like "-L/MyHome/open_source/pqr/lib/sol32/*".
The result is an (almost) empty libC.so that depends on libA and libB, but is itself not useful. In effect, you create a proxy library that has a little code that get executed at program start and exit, but does nothing useful, and also takes up a little of the program address space.
CC -G -o libC.so -L. -lA -lB -R.
does not work because no files are specified as components of cool.so. This version of the command does not even create a dependency on one.so and two.so because they are not mentioned anywhere. If you use older C++ compilers, you get an (almost) empty library that itself is useless, in the sense that it has only do-nothing code that takes up space and execution time in exchange for no benefit. Trying to create it is almost certainly an error, which is why the current compilers do not allow it.
CC -mt -i -library=stlport4 -z defs -z text -G -h cool.so -L/workspaces/PROGRAMS/ \ -g -lc -lCrun -lumem -m32 -o /workspaces/PROGRAMS/cool.so usage: CC [ options ] files. Use 'CC -flags' for details
In this case, the -L option has no effect, and you now have file two.so on the command line, making it a valid command, although it probably does not do what you intended.
vijaygr wrote:... for some definition of "work". If you mean "no error messages", then it worked. If you mean "did something useful," I suspect not.
The same set of commands used to work for our project with previous versions of Studio.
Now, for whatever reasons, it has been broken or not supported in Studio 12.3 & we are kind of stuck with compilation/linking issue.We do not intend to restore the old, incorrect, behavior. You should not want your old build process to work. You should be happy that the compiler now points out the error in the process.
1) Do we have to raise any ticket with Oracle to get it resolved from Oracle side?, or
2) Change anything specifically in the command line options or the way the shared libraries are being built (apart from using ld instead of CC - due to the reason stated in my previous reply).Let's assume that the library in question, call it libC, was empty, and merely depended on other shared libraries. There is no reason to build an empty library, so don't build it. Assuming libC depended on libA and libB, remove the command to build libC, and replace uses of libC with libA and libB. Example:
CC -G -o libC.so -lA -lB ... CC -o myprog -lC ...
Alternatively, you can choose to put something useful in libC. Change the command line that builds libC to include object code. Then you don't need to change anything else. I don't recommend this solution, since the more shared libraries you have, the more complicated your build and distribution process is, and the longer it takes the application to start running.
[omit building libC.so] CC -o myprog -lA -lB ...