符号未找到(ldd)，但它在那里(nm)

Question

我的应用程序抱怨它找不到一个符号：

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

ldd也这么说：

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)

然而，符号就在那里-- nm就是这么说的：

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

但正如你所看到的: Shndx=UNDEF。那是什么意思？我想如果有什么东西是不确定的，那就根本不存在了。但不知何故，它就在那里，尽管我的申请找不到它。

系统: Solaris 10 / UltraSPARC我的应用程序和所有库都是64位的，/foo在LD_LIBRARY_PATH_64中(/bar不在)。

编辑:与此同时，我知道民主阵线就像“需要在另一个库中解决”。我还找到了符号_1cDstdEcerr的lib --它是libCstd.so，在/usr/lib中。或者更准确地说(因为我们需要64位变量) /usr/lib/64。因此，它位于系统的默认库搜索路径之一，由crle显示。现在的问题是:当包含符号的库位于系统的搜索路径时，如何才能不解决它呢？

Answer 1

它没有得到解决，大概是因为您没有将它包含在被传递给链接器的编译标志中。

如果你有

LDFLAGS += -lCstd

在Makefile中，应该传递它，并且链接器会做正确的事情(假设您使用的是标准编译规则，它将$(LDFLAGS)附加到编译器和链接器调用中)。