C++ 的 AIX xlC 交叉编译/链接找不到 C 符号
我正在尝试使用 xlc/xlC 编译器在 AIX 上进行交叉编译。
当代码在另一台机器上使用默认设置时，可以成功编译。代码实际上通过交叉编译成功编译，但问题出在链接器上。这是将对象链接在一起的命令：
$(CHILD_OS)/usr/vacpp/bin/xlC -q32 -qnolib -brtl -o $(EXECUTABLE) $(OBJECT_FILES)
-L$(CHILD_OS)/usr/lib
-L$(CHILD_OS)/usr/vacpp/lib/profiled
-L$(CHILD_OS)/usr/vacpp/lib
-L$(CHILD_OS)/usr/vac/lib
-L$(CHILD_OS)/usr/lib
-lc -lC -lnsl -lpthread
-F$(CHILD_OS)$(CUSTOM_CONFIG_FILE_LOCATION)
当我尝试链接代码时，我得到几个未定义的符号： .setsockopt(int,int,int,const void*,unsigned long), .socket(int,int,int), .connect(int,const sockaddr*,unsigned long) 等。
我发现缺少的符号是来自标准 C 库 libc.a。当我用 nm 查找正在拾取的 libc.a 的符号时，这些符号确实存在。我猜测 C++ 可能存在无法读取 C 对象的问题，但我确实是在黑暗中拍摄。
I am attempting to cross-compile on AIX with the xlc/xlC compilers.
The code compiles successfully when it uses the default settings on another machine. The code actually successfully compiles with the cross-compilation, but the problem comes from the linker. This is the command which links the objects together:
$(CHILD_OS)/usr/vacpp/bin/xlC -q32 -qnolib -brtl -o $(EXECUTABLE) $(OBJECT_FILES)
-L$(CHILD_OS)/usr/lib
-L$(CHILD_OS)/usr/vacpp/lib/profiled
-L$(CHILD_OS)/usr/vacpp/lib
-L$(CHILD_OS)/usr/vac/lib
-L$(CHILD_OS)/usr/lib
-lc -lC -lnsl -lpthread
-F$(CHILD_OS)$(CUSTOM_CONFIG_FILE_LOCATION)
When I attempt to link the code, I get several Undefined symbols:
.setsockopt(int,int,int,const void*,unsigned long), .socket(int,int,int), .connect(int,const sockaddr*,unsigned long), etc.
I have discovered that the symbols missing are from the standard c library, libc.a. When I looked up the symbols with nm for the libc.a that is being picked up, the symbols do indeed exist. I am guessing that there might be a problem with the C++ being unable to read the C objects, but I am truly shooting in the dark.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来这可能是一个 C++ 名称修改问题。
在目标文件上运行
nm以找出它们正在寻找的符号。然后将确切的名称与库进行比较。然后检查编译命令，以确保包含正确版本的头文件 - 也许它错误地包含了父操作系统的副本？
Sound like it might be a C++ name mangling problem.
Run
nmon the object files to find out the symbols that they are looking for. Then compare the exact names against the libraries.Then check the compilation commands, to ensure that the right version of the header files is being included - maybe it's including the parent OS's copy by mistake?
我最终能够解决这个问题。看起来我正在使用 C++ 编译器来处理 .c 文件。对 C 文件使用 xlc 编译器而不是 xlC 编译器解决了此问题。
I was eventually able to get around this. It looks like I was using the C++ compiler for .c files. Using the xlc compiler instead of the xlC compiler for C files fixed this problem.