GCC ARM 交叉编译，诸如对`__cxa_end_catch@CXXABI_1.3' 的未定义引用之类的错误表示什么? [英] GCC ARM Cross-Compiling, what do errors like undefined reference to `__cxa_end_catch@CXXABI_1.3' indicate?
问题描述
我使用面向 FPGA SoC 的英特尔嵌入式开发套件成功地为英特尔 Cyclone V SoC 构建了一个测试应用程序.此应用程序链接到某些特定于目标系统的库.
I successfully built a test application for an Intel Cyclone V SoC with the Intel Embedded Development Suite for FPGA SoCs. This application links against some target system specific libraries.
由于 EDS 附带的 GCC 已经过时，我需要更新的 C++ 功能，我想用我下载的当前版本的 arm-linux-gnueabihf-g++ 编译整个内容此处 来自 ARM 网站.
As the GCC shipped with the EDS is quite outdated and I need newer C++ features, I wanted to compile the whole thing with a current version of arm-linux-gnueabihf-g++ which I downloaded here from the ARM website.
使用最近的 GCC 编译使用原始工具链构建良好的同一个项目会导致很多错误，如下所示:
Compiling the same project that builds fine with the original toolchain with the recent GCC leads to lots of errors like this:
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: intelFPGARootDir/18.1/hld/host/arm32/lib/libalteracl.so: undefined reference to `__cxa_end_catch@CXXABI_1.3'
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: intelFPGARootDir/18.1/hld/host/arm32/lib/libalteracl.so: undefined reference to `std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream(std::string const&, std::_Ios_Openmode)@GLIBCXX_3.4'
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: intelFPGARootDir/18.1/hld/host/arm32/lib/libalteracl.so: undefined reference to `std::cerr@GLIBCXX_3.4'
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: intelFPGARootDir/18.1/hld/host/arm32/lib/libalteracl.so: undefined reference to `operator delete(void*)@GLIBCXX_3.4'
libalteracl.so 是英特尔分发的目标系统特定库之一.显然这里有些不匹配，但是我不确定确切的问题是什么.因此，我需要解释一下如何解释这些错误以及如何修复它们.
libalteracl.so is one of the target system specific libraries distributed by Intel. Obviously something doesn't match here, however I'm not sure what's the exact problem. So, I need some explanation of how to interpret this errors and what could be done to fix them.
由于评论中出现了一些问题，这里有一些额外的信息
目标架构是双核 ARM Cortex A9.我在上面链接的 ARM 网站上加载了 AArch32 target with hard float (arm-linux-gnueabihf) 下列出的 ARM.
Target Architecture is a Dual-Core ARM Cortex A9. I loaded the ARM listed under AArch32 target with hard float (arm-linux-gnueabihf) on the ARM website linked above.
构建是由 CMake/CLion 完成的.提取生成的Compiler/Linker调用如下:
The build is done by CMake / CLion. The extracted generated Compiler/Linker calls are as follows:
编译:
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -DCL_HPP_MINIMUM_OPENCL_VERSION=110 -DCL_HPP_TARGET_OPENCL_VERSION=200 -DJUCE_APP_CONFIG_HEADER=\"myProjectDir/JuceLibraryCode/AppConfig.h\" -DOPEN_CL_INTEL_FPGA -D_DEBUG=1 -IsomeFrameworkDir/JUCE/modules -IintelFPGARootDir/18.1/hld/host/include20 -g -std=gnu++11 -o CMakeFiles/HostApplication.dir/Source/Main.cpp.o -c myProjectDir/Source/Main.cpp
链接:
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -g -LintelFPGARootDir/18.1/hld/board/de10_standard/arm32/lib -LintelFPGARootDir/18.1/hld/host/arm32/lib -LintelFPGARootDir/18.1/hld/host/arm32/lib -Wl,--no-as-needed -lalteracl -lintel_soc32_mmd -lstdc++ -lelf CMakeFiles/HostApplication.dir/Source/Main.cpp.o CMakeFiles/HostApplication.dir/JuceLibraryCode/include_juce_core.cpp.o -o HostApplication -lrt -ldl -lpthread
libalteracl.so 应该是一个 32 位的库，因为整个目标架构是 32 位的
libalteracl.so should be a 32 Bit library as the whole target Architecture is 32 Bit
推荐答案
看来，这是因为你的工具链中的 libstdc++ 没有提供版本化符号...
It seems, the reason for this is that libstdc++ in your toolchain does not provide versioned symbols...
在我的主机上，我得到
$ readelf -sW /usr/lib64/libstdc++.so.6 | c++filt | grep std::cerr | grep @
3091: 000000000018d340 272 OBJECT GLOBAL DEFAULT 25 std::cerr@@GLIBCXX_3.4
$ readelf -sW /usr/lib64/libstdc++.so.6 | grep __cxa_end_catch | grep @
1997: 000000000008fe60 131 FUNC GLOBAL DEFAULT 11 __cxa_end_catch@@CXXABI_1.3
但我没有看到您提供链接的工具链的版本符号:
But I don't see the versioned symbols for the toolchain you provided a link to:
$ readelf -sW ./arm-linux-gnueabihf/libc/usr/lib/libstdc++.so.6.0.25 | c++filt | grep std::cerr | grep @
(nothing)
所以我认为 libalteracl.so 已与提供符号版本化版本的 libstdc++ 相关联.也许你会更幸运地使用来自同一供应商的早期工具链.
So I think libalteracl.so has been linked against libstdc++ that provided versioned versions of the symbols. Maybe you'll have more luck with earlier toolchains from the same vendor.
来自手册:
先决条件
支持版本化 ABI 的最小环境:受支持的动态链接器、足够老式的 GNU 链接器以理解解散的 C++ 名称通配 (ld) 或 Sun 链接器、使用 g++ 编译的共享可执行文件和共享库(libgcc_s、libstdc++) 由具有兼容 ABI 的编译器 (g++) 编译.呼.
Minimum environment that supports a versioned ABI: A supported dynamic linker, a GNU linker of sufficient vintage to understand demangled C++ name globbing (ld) or the Sun linker, a shared executable compiled with g++, and shared libraries (libgcc_s, libstdc++) compiled by a compiler (g++) with a compatible ABI. Phew.
最重要的是，还有一个额外的限制:libstdc++ 直到 3.1.0 版本才尝试版本符号(或优雅地老化).
On top of all that, an additional constraint: libstdc++ did not attempt to version symbols (or age gracefully, really) until version 3.1.0.
大多数现代 GNU/Linux 和 BSD 版本，尤其是使用 GCC 3.1 及更高版本的版本，将满足上述要求，Solaris 2.5 及更高版本也是如此.
Most modern GNU/Linux and BSD versions, particularly ones using GCC 3.1 and later, will meet the requirements above, as does Solaris 2.5 and up.
配置
事实证明，大多数更改默认行为的配置选项都会影响导出符号的重整名称，从而影响版本控制和兼容性.
It turns out that most of the configure options that change default behavior will impact the mangled names of exported symbols, and thus impact versioning and compatibility.
有关配置选项的更多信息，包括 ABI 影响，请参阅:此处
For more information on configure options, including ABI impacts, see: here
有一个标志明确处理符号版本控制:--enable-symvers.
There is one flag that explicitly deals with symbol versioning: --enable-symvers.
这篇关于GCC ARM 交叉编译，诸如对`__cxa_end_catch@CXXABI_1.3' 的未定义引用之类的错误表示什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
