This content has been marked as final. Show 22 replies
Thanks for such a prompt response.
I found the resolution of this linking issue by looking at the Compiler command line. Actually I built the application libraries using -Qoption CC -xcomdat but the main program was not being built using it. I introduced the same in command line for main program and these linking error went away.
But now I am having some other problem.
I am building the program with the option of -library=%none and getting following error with the xerces-c library.
Undefined first referenced
symbol in file
std::basic_ostream<char,std::char_traits<char> >&std::basic_ostream<char,std::char_traits<char> >::write(const char*,long) /opt/xerces/lib/libxerces-c.so
std::basic_ostream<char,std::char_traits<char> >&std::basic_ostream<char,std::char_traits<char> >::flush() /opt/xerces/lib/libxerces-c.so
Now if I introduce -lCstd in the link line this error goes away but then linker complains about dlopen() and dlclose(). If I introduce -lc in link line, this error also goes away and application builds with link warnings. But when I start the application, it fails to come up.
Is there a way to introduce the reference of these libraries (-lCstd -lCrun etc) with -library=%none options.
First , comdat does not work properly and is not supported in C++ 5.7. Remove all uses of the the option, and recompile all the code.
Second, you open up a can of worms if you use -library=%none but want to link system libraries like libCstd. By default, the CC command links the needed system libraries in the right order, which depends on the totality of the command line options. It is difficult and not always possible to get the right system libraries linked in the right order using
The option is provided for programmers who want to prevent linking of system libraries.
If you have a specific need to use -library=%none but still want to link system libraries, add the -dryrun option to what would be an ordinary CC link command. That is, something like this:
CC -dryrun -o myprog *.o mylib.a
The output of the CC command will show the "ld" command that does the actual program link. You can use that ld command, modifying it as needed. You have to regenerate the ls command if you make changes in how the program is built, or in any command-line options.
But why do you want to use library=%none? What problem are you trying to solve?
Finally, C++ 5.7 is End Of Life. Please consider upgrading to the free Sun Studio 11 as I previously suggested.
Roguewave Suggests using -library=%none to prevent linkage to libCstd. It provides its own library for their STL implementation. Its not possible to use both -lCstd and -lstd(RW) at the same time.
Now when I use xerces it tries to locate something in the Cstd library and results in the error. I found that its a bug with xerces library.
As far as I can think the only option is to remove the reference of iostream from xerces library. Can you suggest any thing else??
Unfortunately I cannot move to Studio 11 right now and I have to live with C++ 5.4 for the time being.
Thanks a lot for helping me out.
If RW suggests -library=%none, the advice is not correct.
As explained in the C++ Users Guide, the way to prevent linking libCstd is to use the option
The compiler will not find any of the headers associated with libCstd, and will not attempt to link libCstd. It will link the other system libraries that are required, like libCrun and libc. That is exactly the effect you want.
I have partially similar issues with Studio 9 - yes I know about Studio 11, but 9 is the current standard where I work, imagine that we're just upgrading from WS6U2....
Code that was linking just fine with WS6U2 now spews out dozens of undefined symbols from the std library, essentially for ios and streams. We're not using any specific library options, so linking with Cstd, which I assumed should have been sufficient.
We are using -z now (to work around some weird template instantiation issue at startup I believe), but this does not seem to make any difference when turned off.
I have been able to build other software (such as Qt 3.3.8) flawlessly, so I'm at a loss here. Any ideas are welcome.
I can't say without seeing the error messages, but my guess is that you did not update the C++ system libraries on the computer where you are running the compiler (or the application, if the complaints are at application run time).
Each Sun Studio release has a minimum set of patches that are required on the computer running Sun Studio. Some of those patches are also required on computers that run applications built with Sun Studio.
The Release Notes for Sun Studio list the required patches, and the patches are included on the installation CD.
You can also see the Sun Studio 9 release notes here
and download patches here
Indeed, the machine doesn't have the minimal libC patch revision (15 instead of 17). I knew I should have installed the compiler myself :/
Thanks a lot, I'll upgrade the patches and let you know how it turns out.
And of course, everything links like a charm once libC is correctly patched. Boy do I love my IT guys.