【问题标题】:Linking C++ to static library; undefined reference errors将 C++ 链接到静态库;未定义的参考错误
【发布时间】:2018-02-28 10:52:08
【问题描述】:

我正在尝试将一个小型 C++ 测试程序 main.o 链接到第 3 方静态库,但得到一些莫名其妙的 undefined reference 错误。

具体来说:

g++  -o secoTest -lpthread  main.o  libEAPI.a
main.o: In function `main':
main.cpp:(.text+0x29fe): undefined reference to `EApiWDog_SetConfigAndStart(unsigned int, unsigned int, unsigned int, unsigned int, unsigned char, unsigned char, unsigned char)'
main.cpp:(.text+0x33fc): undefined reference to `EApiSetCarrier(unsigned char)'
main.o:main.cpp:(.text+0x3956): more undefined references to `EApiSetCarrier(unsigned char)' follow
main.o: In function `main':
main.cpp:(.text+0x3965): undefined reference to `EApiGPIOGetSerialCfg(unsigned char*)'
main.cpp:(.text+0x3a0a): undefined reference to `EApiSetCarrier(unsigned char)'
main.cpp:(.text+0x3a19): undefined reference to `EApiGPIOSetSerialCfg(unsigned char)'
main.cpp:(.text+0x3adf): undefined reference to `EApiFanEnable(unsigned int, unsigned char)'
main.cpp:(.text+0x3b83): undefined reference to `EApiFanDisable()'
collect2: ld returned 1 exit status

但是,符号似乎出现在库中。例如:

nm --demangle libEAPI.a | grep EApiFanDisable
00003c20 T EApiFanDisable

奇怪的是符号不完全相同。在main.o 中是

nm --demangle main.o | grep EApiFanDisable
         U EApiFanDisable()

所以一个有() 而一个没有。

同样,

nm --demangle main.o | grep EApiSetCarrier
         U EApiSetCarrier(unsigned char)
nm --demangle libEAPI.a | grep EApiSetCarrier
000015d0 T EApiSetCarrier

如果我完全从命令行中省略了库(例如,g++ -o secoTest -lpthread main.o),它会按预期显示很多错误。

main.o 引用带有和带有() 的外部符号[为什么?]:

     U EApiVgaSetBacklightEnable
     U EApiWDogStart
     U EApiWDogTrigger
     U EApiFanEnable(unsigned int, unsigned char)
     U EApiFanDisable()
     U EApiSetCarrier(unsigned char)

但图书馆只有符号没有() [为什么?]:

000020e0 T EApiVgaSetBacklightEnable
000024e0 T EApiWDogStart
000026f0 T EApiWDogTrigger
00003c20 T EApiFanDisable
00003bf0 T EApiFanEnable
000015d0 T EApiSetCarrier

这会是未定义引用的原因吗?我将如何解决它?不知道下一步该往哪里看...

(我无法修改第三方库,但有头文件。)

编辑

正如 lisyarus 所建议的,这里是 nm,没有 --demangle。确实,符号不同。 g++ 编译器 (v4.4.7) 为某些符号生成一个损坏的符号 而库总是有普通符号... [为什么?]

nm libEAPI.a main.o | grep EApiWDogTrigger
000026f0 T EApiWDogTrigger
         U EApiWDogTrigger
nm libEAPI.a main.o | grep EApiSetCarrier
000015d0 T EApiSetCarrier
         U _Z14EApiSetCarrierh

【问题讨论】:

  • nm 没有拆解显示什么?可能会发生该库是使用不同的编译器/标准/等编译的,并且损坏的名称有所不同。

标签: c++ static-libraries


【解决方案1】:

libEAPI.a 包含在C 而非C++ 中编译的目标文件。 因此,这些符号没有被命名,不能用于 解析由 C++ 生成的名称损坏的函数引用 代码。

运行:

nm libEAPI.a | grep EApiFanDisable

你不会看到任何变化。

运行:

nm main.o | grep EApiFanDisable

你会看到损坏的符号,它既不是EApiFanDisable也不是EApiFanDisable() 但更像_Z14EApiFanDisablev,链接器实际上正在尝试 解决。

为避免这些链接错误,您必须通知您的 C++ 编译器,当它 编译 libEAPI 的头文件,其中的声明具有 外部 C 链接,因此它将发出对声明的符号的未损坏引用:像这样:

ma​​in.cpp

...
extern "C" {
#include "EAPI.h"   // or whatever
}

...

顺便说一句,这个命令行:

g++  -o secoTest -lpthread  main.o  libEAPI.a

将无法在基于 Debian 的发行版上链接 libpthread(Ubuntu 等) 比 Debian 6 更新,因为从那时起所有库都必须按依赖顺序链接:

g++  -o secoTest main.o  libEAPI.a -lpthread

更好的是,不要使用不可移植的-lpthread,而是通过可移植的 用于编译和链接的选项-pthread。这意味着:做任何事 使用 Posix 线程支持编译/链接是正确的

【讨论】:

  • 非常有见地,感谢您提供宝贵的信息:)
猜你喜欢
  • 1970-01-01
  • 2023-03-05
  • 1970-01-01
  • 2020-07-24
  • 2014-04-28
  • 2010-10-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多