Не срабатывает кросскомпиляция в CMake (не находит тулчейны)

И какой компилятор задан в ./platforms/linux/arm-gnueabi.toolchain.cmake?

cat platforms/linux/arm-gnueabi.toolchain.cmake

set(GCC_COMPILER_VERSION "" CACHE STRING "GCC Compiler version")
set(GNU_MACHINE "arm-linux-gnueabi" CACHE STRING "GNU compiler triple")
include("${CMAKE_CURRENT_LIST_DIR}/arm.toolchain.cmake")

Ровно то, что и нужно. Я ж сначала посмотрел, потом нужный тулчейн собрал, чтоб не дай бог cmake не обиделся.

Нужно разбираться почему он задал компилятором /usr/bin/c++ который не умеет в ARM. У тебя установлен вообще компилятор который умеет собирать ARM?

Я в crossdev не понимаю, делал только свои toolchain.

У тебя установлен вообще компилятор который умеет собирать ARM?

Да вот же он:

den@zuiho ~ $ arm-linux-gnueabi-g++ -v
Используются внутренние спецификации.
COLLECT_GCC=arm-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-linux-gnueabi/13/lto-wrapper
Целевая архитектура: arm-linux-gnueabi
Параметры конфигурации: /var/tmp/portage/cross-arm-linux-gnueabi/gcc-13.3.1_p20240614/work/gcc-13-20240614/configure --host=x86_64-pc-linux-gnu --target=arm-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-linux-gnueabi/gcc-bin/13 --includedir=/usr/lib/gcc/arm-linux-gnueabi/13/include --datadir=/usr/share/gcc-data/arm-linux-gnueabi/13 --mandir=/usr/share/gcc-data/arm-linux-gnueabi/13/man --infodir=/usr/share/gcc-data/arm-linux-gnueabi/13/info --with-gxx-include-dir=/usr/lib/gcc/arm-linux-gnueabi/13/include/g++-v13 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/arm-linux-gnueabi/13/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 13.3.1_p20240614 p17' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-poison-system-directories --with-sysroot=/usr/arm-linux-gnueabi --disable-gcov --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --with-float=soft --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp --disable-fixincludes
Модель многопоточности: posix
Supported LTO compression algorithms: zlib
gcc версия 13.3.1 20240614 (Gentoo 13.3.1_p20240614 p17)

А используется почему то не он, попробуй в файле написать

set(CMAKE_CXX_COMPILER arm-linux-gnueabi-g++)
set(CMAKE_C_COMPILER arm-linux-gnueabi-gcc)

Это в файле с тулчейном?

Да, или можешь аргументами задать -DCMAKE_{C,CXX}_COMPILER.

Вместо

-- Check for working CXX compiler: /usr/bin/c++

Должно появится

-- Check for working CXX compiler: arm-linux-gnueabi-g++

Мда. Попробую

Ну да, сработало. Не думал, что доживу до такого чтобы заявить, что лучше бы оно автотулзами собиралось.

любая тулза будет глючить и не работать, если пытаться использовать ее, игнорируя то что написано в ее доках.

Я строго по докам и собирал, представь себе.

А что в этом ./platforms/linux/arm-gnueabi.toolchain.cmake находится?

Не думал, что доживу до такого чтобы заявить, что лучше бы оно автотулзами собиралось.

Так у автотулзов обычно кросс-компиляция сама заводится, достаточно указать --host=, а для cmake нужен toolchain-файл, причём правильно написанный. cmake это вообще переделка autotools с одного чудовищного языка на ещё более чудовищный, и при этом половина фич от первого во втором примотана изолентой сбоку.

Мало. Вот тебе, для примера, самое важное из содержимого моего тулчейн-файла для AVR (утащено откуда-то с инета):

…
##########################################################################
# executables in use
##########################################################################
find_program(AVR_CC avr-gcc)
find_program(AVR_CXX avr-g++)
find_program(AVR_OBJCOPY avr-objcopy)
find_program(AVR_SIZE_TOOL avr-size)
find_program(AVR_OBJDUMP avr-objdump)

##########################################################################
# toolchain starts with defining mandatory variables
##########################################################################
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR avr)
set(CMAKE_C_COMPILER ${AVR_CC})
set(CMAKE_CXX_COMPILER ${AVR_CXX})

…

Если совсем коротко, обрати внимание на CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_PROCESSOR, CMAKE_C_COMPILER и CMAKE_CXX_COMPILER — они должны быть заданы

Лучше сразу начинать чтение с https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-linux

В моем собственном toolchain они заданы, в том, который с библиотекой идет - нет.

Не думал, что доживу до такого чтобы заявить, что лучше бы оно автотулзами собиралось.

CMake, конечно, та ещё параша параш и повозить лицом по столу ущербности CMake его фанатиков на ЛОРе всегда весело, но возвращаться к autotools’ам это тоже шаг назад.

Лучше будет если CMake и autotools начнёт вытеснять новая билд-система.

утащено откуда-то с инета

А в этом, кстати, самая основная проблема CMake’а. Его пользователи как последние виндузятники-парашники постоянно таскают какие-то заскорузлые говноскрипты из разных частей интернета, см. CMake 3.28 (комментарий)

Создать относительно всеобъемлющий реп с уже проверенными скриптами сообщество идиотов из Kitware не осилило. Они попытались и обосрались. Теперь дистрибутив CMake тянет с собой протухшие скрипты всяких там SDL1 до момента когда они ещё не обосрались, а вот всякие SDL2 и др. – ищите сами по инету с огромным мешком.

Вот и по сабжевой проблеме ТС’а. Разработчик библиотеки вместо того, чтобы сходить в официальный реп и взять скрипт поддержки дефолтного arm-linux-gnueabi пошёл в интернет и как последняя виндузота нашёл где-то корявый говно-скрипт который положил в дерево файлов своей либы с ожидаемым результатом.

CMake давно уже захламляет интернет и GitHub своими убогими и кривоработающими тулчейн-файлами, файндмодулями, где каждый их пишет на свой лад в итоге все работает криво, косо, вот так как в сабжевом случае.

Кто-нибудь может пояснить, почему C++-программисты создали себе CMake вместо нормальной системы сборки? Ведь умные же люди. И как вообще настолько убогий и отвратный проект стал негласным стандартом в мире C/C++ разработки? Прямо родили второй autotools, а ведь альтернатив была огромная масса.

Почему разработчики под Windows его так любят, а разработчики под Linux переводят с него проекты на Meson?

ППКС. Даже в тех же autotools достаточно сделать ./configure --build=x86_64 --host=arm-linux-gnueabi и оно сгенерит правильный Makefile.

Создать относительно всеобъемлющий реп с уже проверенными скриптами сообщество идиотов из Kitware не осилило.

А кто то осилил? Странная претензия к CMake, учитывая что нигде вроде бы такого нету в нормальном виде. Есть репозиторий vcpkg, там много чего, и PkgConfig.

О, точно, забыл про эту страницу справки

У CMake есть проблемы, как и у любого проекта. У него есть и сильные стороны, как у любого вменяемого проекта. Если проводить параллели с Meson, что у него с аналогами:

1. CTest
2. CPack
3. Поиском библиотек платформонезависимым
4. Кросс-компиляцией
5. Аналогом ExternalProject

?

Почему разработчики под Windows его так любят, а разработчики под Linux переводят с него проекты на Meson?

Кто в здравом уме будет переводить систему сборки проектов C/C++ с C/C++ на питон?

А при чем тут это?

Кросс-компиляцией

Нормально у него все с кросскомпиляцией, я под эмбед использую meson.

Зачем ты спрашиваешь у EXL конкретику? Всё, на что он способен, это изливать желчь в сторону cmake. Это тупой, ограниченный хейтер.