Переопределение имен утилит из binutils

Question

Собственно вот какой вопрос ... Всем известно, что если в скрипте перед командой ./configure сделать такую объявку:

export CC=clang
export CXX=clang++

То последующие инструменты сборки постараются вместо компилятора GCC использовать clang. С этим всем понятно.

Но возникла другая ситуация. Я использую кросс-компиляторы из проекта mxe.cc для сборки GUI-библиотеки nana. В nana система сборки базируется на cmake. У каждого "комплекта" свой cmake. И вот смотрите мой скрипт:

#!/bin/sh

export PATH=/home/majestio/Dev/cross/mxe/usr/bin:$PATH
export TARGET=x86_64-w64-mingw32.shared

export CC=$TAGRET-gcc
export CXX=$TAGRET-g++
export LD=$TAGRET-ld
export DLLTOOL=$TAGRET-dlltool
export DLLWRAP=$TAGRET-dllwrap
export AS=$TAGRET-as
export AR=$TAGRET-ar
export RANLIB=$TAGRET-ranlib
export NM=$TAGRET-nm
export WINDRES=$TAGRET-windres
export PKG_CONFIG=$TAGRET-pkg-config

$TARGET-cmake .. -DCMAKE_BUILD_TYPE="Release" -DBUILD_SHARED_LIBS:BOOL=ON
make

По сути он запускает x86_64-w64-mingw32.shared-cmake. Тот игнорирует все мои переопределения - я пробовал. Он сам находит нужные компиляторы из "своего" комплекта, а вот dlltool не находит. Хотя в комплекте он есть, и называется он x86_64-w64-mingw32.shared-dlltool.

Поэтому пару вопросов

Какие из моих переопределений вообще неверные, ну кроме CC и CXX даже для ./configure?
Как мне приручить cmake к нужным мне переопределениям имен утилит из binutils?

Answer 1

Свою задачу сборки я решил. Хотя остались некоторые вопросы, которые не касаются именно моей задачи. Тем не менее, опишу сделанное - может быть кому-то поможет.

Касаемо ./configure

Скрипт ./configure к binutils никакого отношения не имеет. Это файл, генерируемый системой сборки autotools (а именно autoconf). Достаточно часто ./configure уже присутствует в архиве с исходниками в готовом виде. И кросс-компиляция настраивается просто указанием необходимых параметров.

Касаемо cmake и dlltool

cmake о многих инструментах из binutils тулчейнов просто не знает. Это же и касается dlltool (специфичный инструмент для windows-цели, для генерации библиотеки импорта). О чем "знает" cmake - можно посмотреть, набрав:

cmake --help-variables | less

Как правило, это переменные вида:

CMAKE_<LANG>_COMPILER
CMAKE_<LANG>_COMPILER_AR
CMAKE_<LANG>_COMPILER_RANLIB
CMAKE_<LANG>_LINK_EXECUTABLE
CMAKE_AR
...

Но про dlltool или windres - там ничего нет!

Соответственно, в моем случае никакие манипуляции с параметрами cmake для кросс-компиляции нужного результата не дали. Пришлось смотреть и редактировать исходние конфигурационные файлы проекта, отвечающие за поиск dlltool. В результате получилось следующее.

Мой скрипт сборки приобрел вид:

#!/bin/sh

export MXE=/home/majestio/Dev/cross/mxe/usr
export PATH=$MXE/bin:$PATH
export TARGET=i686-w64-mingw32.shared

$TARGET-cmake .. \
 -DCMAKE_BUILD_TYPE="Release" \
 -DBUILD_SHARED_LIBS:BOOL=ON \
 -DCMAKE_INSTALL_PREFIX=$MXE/$TARGET \ 
 -DCMAKE_DLLTOOL=$MXE/bin/$TARGET-dlltool

А в конфигурационном файле проекта shared_libs.cmake внес правку:

-- shared_libs.cmake-old    2020-02-08 07:30:54.000000000 +0300
+++ shared_libs.cmake   2022-08-20 11:22:33.835154661 +0300
@@ -10,7 +10,7 @@
             set(DLLTOOL OFF)
         else()
             # mingw: If dlltool is found the def and lib file will be created
-            find_program (DLLTOOL dlltool)
+            find_program (DLLTOOL ${CMAKE_DLLTOOL})
             if(NOT DLLTOOL)
                 message(WARNING "dlltool not found. Skipping import library generation.")
             endif()

Это все и решило мою проблему. Библиотеки импорта стали генерироваться.

Надеюсь кому-то поможет.

БЛОГ НА HUSL

Переопределение имен утилит из binutils

Ответы (1 шт):