Question

我使用用于FPGA SoC的英特尔嵌入式开发套件成功地为Intel Cyclone V SoC构建了测试应用程序。此应用程序链接到某些特定于目标系统的库。

由于EDS随附的GCC已过时，并且我需要更新的C ++功能，因此我想用从ARM下载here的最新版本的arm-linux-gnueabihf-g ++编译整个程序。网站。

使用最新的GCC编译使用原始工具链构建良好的同一项目会导致很多错误，如下所示：

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是Intel分发的特定于目标系统的库之一。显然这里不匹配，但是我不确定确切的问题是什么。因此，我需要对如何解释此错误以及如何解决这些错误进行一些解释。

由于评论中出现了一些问题，以下是一些其他信息

目标体系结构是双核ARM Cortex A9。我在上面链接的ARM网站上将 AArch32目标下列出的ARM装入了带有硬浮点（arm-linux-gnueabihf）的。

构建由CMake / CLion完成。提取的生成的Compiler / Linker调用如下：

编译：

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位的

Answer 1

这似乎是因为您的工具链中的libstdc ++没有提供版本化的符号...

在主机上，我得到

$ 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

但是我看不到您提供的链接的工具链的版本符号：

$ readelf -sW ./arm-linux-gnueabihf/libc/usr/lib/libstdc++.so.6.0.25 | c++filt | grep std::cerr | grep @
(nothing)

因此，我认为libalteracl.so已与提供符号版本的libstdc ++链接在一起。也许您会更幸运地使用同一供应商提供的早期工具链。

来自the manual：

先决条件

支持版本化ABI的最小环境：受支持的动态链接器，足够老的GNU链接器可以理解脱钩的C ++名称遍历（ld）或Sun链接器，使用g ++编译的共享可执行文件和共享库（libgcc_s，libstdc ++ ）由具有兼容ABI的编译器（g ++）编译。 ew。

最重要的是，还有一个附加的约束：libstdc ++直到版本3.1.0才尝试对符号进行版本化（或者说，确实优雅地进行了老化）。

大多数现代GNU / Linux和BSD版本（尤其是使用GCC 3.1和更高版本的版本）将满足上述要求，Solaris 2.5及更高版本也将满足以上要求。

配置

事实证明，大多数更改默认行为的配置选项都会影响导出符号的错误名称，从而影响版本控制和兼容性。

有关配置选项（包括ABI影响）的更多信息，请参见：此处

有一个标志专门用于处理符号版本控制：--enable-symvers。

Answer 2

最后，我成功地使用了apt软件包管理器提供的arm-linux-gnueabihf-g ++，它有点老，但支持我需要的所有功能，并且似乎具有库和预期的符号命名功能。因此成功链接。

这现在在目标系统上引入了其他错误，因为由FPGA板制造商预先构建的最小型Linux中的runtinme库并不包含所有必需的功能，因此我必须手动更新系统，但我可能会对此提出另一个问题。

GCC ARM交叉编译，未定义引用__cxa_end_catch@CXXABI_1.3的错误指示什么？

2 个答案: