LINUX.ORG.RU

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

 ,


0

1

В чем состоит проблема: мне надо перебрать некий пакет под архитектуру arm-linux-gnueabi. Как умная Маша собираю себе с помощью crossdev нужный тулчейн: crossdev -S -t arm-linux-gnueabi. Ок. Потом в директории искомого пакета делаю

cmake -S . -B build/ -DCMAKE_TOOLCHAIN_FILE=./platforms/linux/arm-gnueabi.toolchain.cmake
, а в ответ оно мне такое:
-- The CXX compiler identification is GNU 14.2.1
-- The C compiler identification is GNU 14.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:73 (message):
  The C++ compiler

    "/usr/bin/c++"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/home/den/src/opencv/opencv-4.10.0/build/CMakeFiles/CMakeScratch/TryCompile-M78Otx'
    
    Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/gmake -f Makefile cmTC_16743/fast
    /usr/bin/gmake  -f CMakeFiles/cmTC_16743.dir/build.make CMakeFiles/cmTC_16743.dir/build
    gmake[1]: вход в каталог «/home/den/src/opencv/opencv-4.10.0/build/CMakeFiles/CMakeScratch/TryCompile-M78Otx»
    Building CXX object CMakeFiles/cmTC_16743.dir/testCXXCompiler.cxx.o
    /usr/bin/c++   -mthumb  -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi  -fPIE -o CMakeFiles/cmTC_16743.dir/testCXXCompiler.cxx.o -c /home/den/src/opencv/opencv-4.10.0/build/CMakeFiles/CMakeScratch/TryCompile-M78Otx/testCXXCompiler.cxx
    c++: ошибка: unrecognized command-line option «-mthumb»
    gmake[1]: *** [CMakeFiles/cmTC_16743.dir/build.make:78: CMakeFiles/cmTC_16743.dir/testCXXCompiler.cxx.o] Ошибка 1
    gmake[1]: выход из каталога «/home/den/src/opencv/opencv-4.10.0/build/CMakeFiles/CMakeScratch/TryCompile-M78Otx»
    gmake: *** [Makefile:127: cmTC_16743/fast] Ошибка 2
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:127 (enable_language)


-- Configuring incomplete, errors occurred!

Смотрю, что за /usr/bin/c++ - так и есть, это основной компилятор системы. То есть ему пофигу, хочу я сборку на arm или не хочу. А мне надо. Как победить сие?

Да, параметр --toolchain тоже не пашет, я проверял.

Всем спасибо.

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

★★★★★

Последнее исправление: LongLiveUbuntu (всего исправлений: 1)

Ответ на: комментарий от MOPKOBKA

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 не обиделся.

LongLiveUbuntu ★★★★★
() автор топика
Ответ на: комментарий от LongLiveUbuntu

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

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

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

У тебя установлен вообще компилятор который умеет собирать 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)

LongLiveUbuntu ★★★★★
() автор топика
Ответ на: комментарий от LongLiveUbuntu

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

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

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от LongLiveUbuntu

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

Вместо

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

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

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

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от LongLiveUbuntu

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

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

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от LongLiveUbuntu

Мало. Вот тебе, для примера, самое важное из содержимого моего тулчейн-файла для 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 — они должны быть заданы

XMs ★★★★★
()
Последнее исправление: XMs (всего исправлений: 1)
Ответ на: комментарий от LongLiveUbuntu

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

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

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

EXL ★★★★★
()
Ответ на: комментарий от XMs

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

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

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

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

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

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

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

EXL ★★★★★
()
Ответ на: комментарий от EXL

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

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

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от EXL

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

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

?

XMs ★★★★★
()
Ответ на: комментарий от EXL

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

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

raspopov
()