Кросс-компиляция GCC ARM, на что указывают такие ошибки, как неопределенная ссылка на `__cxa_end_catch@CXXABI_1.3 '?

Question

Я успешно создал тестовое приложение для Intel Cyclone V SoC с Intel Embedded Development Suite для FPGA SoC. Это приложение связывается с некоторыми целевыми системными библиотеками.

Поскольку GCC, поставляемый с EDS, довольно устарел, и мне нужны новые функции C ++, я хотел скомпилировать все это с текущей версией arm-linux-gnueabihf-g ++, которую я скачал здесь из веб-сайт ARM.

Компиляция того же самого проекта, который прекрасно строится с оригинальным набором инструментов с недавним 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, с помощью hard float (arm-linux-gnueabihf) на веб-сайте ARM, указанном выше.

Сборка выполняется CMake / CLion. Извлеченные сгенерированные вызовы компилятора / компоновщика выглядят следующим образом:

Компиляция:

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 ++, который предоставил версионные версии символов. Возможно, вам повезет больше с предыдущими наборами инструментов от того же поставщика.

---

С инструкция :

Предпосылки

Минимальная среда, поддерживающая версионный ABI: поддерживаемый динамический компоновщик, компоновщик GNU достаточного уровня, чтобы понимать разборчивое глобалирование имен C ++ (ld) или компоновщик Sun, общий исполняемый файл, скомпилированный с g ++, и общие библиотеки (libgcc_s, libstdc ++ ) компилируется компилятором (g ++) с совместимым ABI. Уф.

Вдобавок ко всему, дополнительное ограничение: libstdc ++ не пытался версировать символы (или на самом деле изящно устарел) до версии 3.1.0.

Большинство современных версий GNU / Linux и BSD, особенно те, которые используют GCC 3.1 и более поздние версии, будут соответствовать вышеуказанным требованиям, как и Solaris 2.5 и выше.

Настройка

Оказывается, что большинство параметров конфигурации, которые изменяют поведение по умолчанию, влияют на искаженные имена экспортируемых символов и, следовательно, влияют на управление версиями и совместимость.

Для получения дополнительной информации о параметрах конфигурации, включая воздействия ABI, см .: здесь

Существует один флаг, который явно связан с версиями символов: --enable-symvers.

Answer 2

В итоге я успешно заполучил его для работы с arm-linux-gnueabihf-g ++, предоставляемым менеджером пакетов apt, который немного старше, но поддерживает все необходимые мне функции и, кажется, имеет именование символов, как и ожидалось библиотекой и поэтому успешно связывается.

Теперь это приводит к появлению других ошибок в целевой системе, поскольку библиотеки runtinme, представленные в этом минимальном Linux, который предварительно собран изготовителем платы FPGA, не содержат всех необходимых функций, поэтому мне придется обновлять систему вручную, но я мог бы открыть другой вопрос по этому поводу.