Ldd does not show dependency on libC/ libCrun or libCstd

Question

When I do an ldd on my executables (built using WS6U2), it does not show that it depends on libC/ libCrun or libCstd. But the executables use the iostream. More over, one of them fails with the below message;
ld.so.1: Rules: fatal: relocation error: file /opt/versant/cur_rel/lib/libcxxcls.so: symbol __1cDstdEcout_: referenced symbol not found
I initially thought the libCstd is not picked up as its path was not set in LD_LIBRARY_PATH. But setting it up right did not fix the issue. I finally had to preload libCstd using LD_PRELOAD to get the executable run.
My questions are;
1) Was the symbol __1cDstdEcout__ defined is some other library earlier and got moved to libCstd?
2) Why ldd does not list any of the C++ libraries (libC, libCrun or libCstd)?
3) What do libC, libCrun and libCstd provide? Does it provide any of the STL classes? I guess most of the STL comes from the headers itself (since most of them are templates)
Edited by: satheeshpaul on Dec 18, 2008 10:12 PM

Answer 1

satheeshpaul wrote:
2) Why ldd does not list any of the C++ libraries (libC, libCrun or libCstd)?Maybe because they are linked statically?
There's more reliable way to check:
$ elfdump -d a.out  | grep NEED
       [0]  NEEDED            0x215               libCstd.so.1
       [1]  NEEDED            0x22d               libCrun.so.1
       [2]  NEEDED            0x269               libm.so.2
       [3]  NEEDED            0x243               libc.so.1If you don't see some library here, then a.out does not declare its dependency on that library. It might get loaded if some other library requests it, but in case of run-time support libraries, executable must declare dependency on those libraries (libCrun and such).
Now, it is very hard to determine whether or not your app was once linked with, say, libCrun statically. If you suspect that this is the case, you need to find a symbol unique to that library and try looking for it in a.out; if it is defined in a.out, it means that libCrun was linked statically; if you don't find it, well, it usually means close to nothing...
One more note: it is an error to mix statically compiled C++ run-time support libraries with their dynamic versions; in other words, if a.out was once linked with libCrun.a, for example, and libCrun.so gets loaded during program execution (it can happen for various reasons, one example is a.out is linked with some shared library that declares dependency on libCrun.so), things might get rough.
3) What do libC, libCrun and libCstd provide? Does it provide any of the STL classes? I guess most of the STL comes from the headers itself (since most of them are templates)You are right, most of STL comes from headers, but not all of STL. It's easy to find out what those libraries provide by looking at global symbols they export:
$ elfdump -s /usr/lib/libCstd.so.1 | c++filt  | lessAlso, each library is described in User's Guide (highly recommended reading when you have particular question on Sun Studio C++ compiler):
http://docs.sun.com/app/docs/doc/806-7991
In short,
Crun - exception support, memory management, etc.
Cstd - STL
iostream - classic iostreams
C - Crun+iostream for compat=4 mode
satheeshpaul wrote:
I initially thought the libCstd is not picked up as its path was not set in LD_LIBRARY_PATH. But setting it up right did not fix the issue.Compiler records location of run-time support libraries when it build executable, so LD_LIBRARY_PATH is never needed unless you want to temporarily substitute one library for another for debugging purposes, for example.
satheeshpaul wrote:
I finally had to preload libCstd using LD_PRELOAD to get the executable run.You need to look at the way that executable was build; the problem must be in the build process somewhere. If you need help with that, please post command line used for final link step.