symbol not found (ldd), but it's there (nm)

Question

My application complains about a symbol that it cannot find:

fatal: relocation error: file /foo/libxslt4c.so.113: symbol __1cDstdEcout_: referenced symbol not found (bar.c:1330)

And ldd says the same:

ldd -d /bar/libxmllib.so
        libc.so.1 =>     /lib/sparcv9/libc.so.1
        [...]
        libxml4c.so.58 =>        /foo/libxml4c.so.58
        libxslt4c.so.113 =>      /foo/libxslt4c.so.113
        [...]
        /platform/SUNW,SPARC-Enterprise/lib/sparcv9/libc_psr.so.1
        /lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
        symbol not found: __1cDstdEcout_                (/foo/libxslt4c.so.113)
        symbol not found: __1cDstdEcerr_                (/foo/libxslt4c.so.113)

However, the symbol is there - that's what nm says:

nm /foo/libxslt4c.so.113.0 | grep __1cDstdEcerr_
[10915] |                   0|                   0|OBJT |GLOB |0    |UNDEF  |__1cDstdEcerr_

But as you can see: Shndx=UNDEF. What does that mean? I thought if something is undefined it's not there at all. But somehow it is there, although my application cannot find it.

System: Solaris 10 / UltraSPARC My application and all libraries are 64bit, /foo is in LD_LIBRARY_PATH_64 (/bar is not).

edit: Meanwhile I know that UNDEF is like "needs to be resolved in another lib". And I also found the lib that really has the symbol _1cDstdEcerr - it's libCstd.so, which is in /usr/lib. Or to be more precise (since we need the 64bit variant) /usr/lib/64. So it's in one of the system's default library search pathes that are shown by crle. Now the question is: how can a symbol not be resolved when the lib that contains it is in the system's search path?

The system doesn't search every possible library in the library path for symbols, just those the program or shared object links with, as listed by `elfdump -d /bar/libxmllib.so`. — alanc, Feb 19 '14 at 04:10

score 4 · Accepted Answer · answered Feb 18 '14 at 22:37

4

It's unresolved presumably because you didn't include it in your compilation flags which got passed to the linker.

If you had

LDFLAGS += -lCstd

in your Makefile, then it should have been passed along and the linker would have done the right thing (assuming that you're using the standard compilation rules which append $(LDFLAGS) to your compiler and linker invocation).

answered Feb 18 '14 at 22:37

James McPherson

2,476
1
12
16

Thank you, but "my application" is actually proprietary software from IBM. Of course I'm not sure about their LDFLAGS, but I'm pretty sure that they've built the software correctly; the problem is rather my Solaris environment. – thorstenhirsch Feb 18 '14 at 23:41
1

The problem isn't almost definitely not your Solaris environment, it's the way the application has been built. You can examine gnarly intricate internals of the app using `elfdump -d /path/to/application`. A RUNPATH or RPATH entry will help you figure out where it's looking for libCstd.so. Sometimes (I've seen this with poorly-packaged GNU software on Solaris) you might find the runpath is gibberish. Fortunately.... you can use the `elfedit` utility to fix problems like that. One of the Solaris linker team wrote an extensive post on the tool, which is really helpful: http://goo.gl/RgxIy8 – James McPherson Feb 19 '14 at 11:34
You're completely right. IBM resolved the issue and sent us a new lib. Thank you very much, James! – thorstenhirsch Mar 03 '14 at 15:38

symbol not found (ldd), but it's there (nm)

1 Answers1