未找到符号 (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 不在）。

编辑：同时我知道 UNDEF 就像“需要在另一个库中解决”。而且我还发现了真正具有符号 _1cDstdEcerr 的库 - 它是 libCstd.so，它位于 /usr/lib 中。或者更准确地说（因为我们需要 64 位变体）/usr/lib/64.因此它位于 crle 显示的系统默认库搜索路径之一中。现在的问题是：当包含符号的库在系统的搜索路径中时，如何不解析符号？

Answer 1

这可能是因为您没有在编译中包含它 传递给链接器的标志。

如果你有

LDFLAGS += -lCstd

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