Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[35.175.202.7] |
|
Сообщ.
#1
,
|
|
|
Буэонос диас, амигос!
Собственно вот какой вопрос ... Всем известно, что если в скрипте перед командой ./configure сделать такую объявку: export CC=clang export CXX=clang++ То последующие инструменты сборки постараются вместо компилятора GCC использовать clang. С этим всем понятно. Но возникла другая ситуация. Я использую кросс-компиляторы из проекта mxe.cc для сборки GUI-библиотеки 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. Поэтому пару вопросов: 1) Какие из моих переопределений вообще неверные, ну кроме CC и CXX даже для ./configure? 2) Как мне приручить cmake к нужным мне переопределениям имен утилит из binutils? |
Сообщ.
#2
,
|
|
|
Свою задачу сборки я решил. Хотя остались некоторые вопросы, которые не касаются именно моей задачи. Тем не менее, опишу сделанное - может быть кому-то поможет.
Касаемо ./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() Это все и решило мою проблему. Библиотеки импорта стали генерироваться. Надеюсь кому-то поможет. |