CODEWITHSUNDEEP
solarissymbolssolaris-10lddnm
thorstenhirsch
thorstenhirsch

Reputation: 198

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

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?

Upvotes: 1

Views: 3861

Answers (1)

James McPherson
James McPherson

Reputation: 2576

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).

Upvotes: 4

Related Questions