Для сборки под Windows потребуются инструменты Build Tools для Visual Studio 2019, которые можно найти на странице https://visualstudio.microsoft.com/ru/downloads/. Также потребуется программа для конфигурации сборки cmake. Для сборки в командной строке предварительно нужно запустить командный файл для Visual Studio Developer Command Prompt (в 2019 версии это команда C:Program Files (x86)Microsoft Visual Studio2019BuildToolsCommon7Toolsvsdevcmd ).
Для сборки под Linux рекомендуется запускать следующий контейнер docker:
sudo docker run -it -v _ :/usr/src/myapp rikorose/gcc-cmake
Пример программы
В общей папке для компьютеров с операционными системами Linux и Windows (один или оба компьютера – виртуальные машины) создайте папку с проектом и разместите в ней следующие исходные коды:
- в папке src файлы get_os_name.c и main.c ;
- в папку include файл get_os_name.h .
Содержимое файла get_os_name.c :
#include «get_os_name.h» char* get_os_name()
Содержимое файла get_os_name.h :
КАК СДЕЛАТЬ СВОЮ ПРОГРАММУ ЗА 5 МИНУТ НА ВИНДОВС\DEVEL NEXT FOR WINDOWS
#ifndef __GET_OS_NAME_H__ #define __GET_OS_NAME_H__ char* get_os_name(); #endif
Содержимое файла main.c :
#include «stdio.h» #include «get_os_name.h» int main ()
Соберите пример под Windows:
cl -I «include» srcmain.c srcget_os_name.c
gcc -I «include» src/main.c src/get_os_name.c
Проверьте его работоспособность в обеих системах.
Сборка с помощью cmake
Создайте новый каталог для изучения примера сборки с помощью cmake и скопируйте в него папки src и include вместе с файлами.
Добавьте в новый каталог файл CMakeLists.txt :
cmake_minimum_required(VERSION 3.5) project(print_os_name) add_executable(print_os_target src/main.c src/get_os_name.c) target_include_directories(print_os_target PRIVATE $/include)
В первой строчке конфигурации (программы для cmake) мы задаем минимальную версию cmake. Во второй – имя проекта.
Функция add_executable добавляет в проект задачу (target, цель) собрать исполняемый файл (программу). Первым аргументом этой функции является имя задачи, последующие аргументы – файлы исходных кодов.
Функция target_include_directories задает для задачи каталог с включаемыми (include, заголовочными) файлами. Первый аргумент – задача. Далее указывается область действия этой функции ( PRIVATE – только указанная задача, PUBLIC – весь проект). После чего указывается каталог.
В последней строке показано использование переменных cmake. Переменная PROJECT_SOURCE_DIR равна пути к каталогу проекта.
Сборка под Windows
Создайте каталог wbuild и перейдите в него.
Выполните в нем команду:
cmake ..
Программа cmake при запуске требует один аргумент – каталог проекта, в котором должен находиться файл CMakeLists.txt . Двоеточие как в Windows, так и в Linux означает родительский каталог по отношению к текущему.
При выполнении cmake пытается найти в операционной системе средства для сборки программ. После этого найденные средства для сборки тестируются. Далее генерируются конфигурационные файлы для сборки программы с помощью найденных средств сборки. Если на каком-либо этапе произойдет ошибка, то будет выдано соответствующее предупреждение.
При успешном выполнении cmake создаст в каталоге wbuild файл с именем каждой задачи и расширением .vcxproj . В терминах Visual Studio это называется проектом (project).
Также в этом каталоге будет создан файл с именем проекта и расширением .sln . В Visual Studio это называется решением (solution). Оно содержит в себе все проекты, соответствующие задачам в cmake, а также некоторые дополнительные проекты.
Соберите программу с помощью программы:
msbuild или
По умолчанию будет создана отладочная версия программы, которую можно найти в папке Debug . Можно также создать рабочую версию, указав msbuild ключ -p:Configuration=Release (результат будет в папке Release ).
Сборка под Linux
Создайте каталог lbuild и перейдите в него.
Выполните в нем команду:
cmake ..
Соберите программу с помощью программы:
make
Команда make собирает проект в текущей папки (понятие проекта в make и cmake совпадают). В результате получится готовая программа, имя которой совпадает с именем проекта. Запустите и проверьте правильность ее работы.
Статические библиотеки
Код функций из статической библиотеки помещается в файл программы во время ее сборки.
Создайте новый каталог для изучения примера со статической библиотекой и скопируйте в него папки src и include вместе с файлами.
Добавьте в новый каталог файл CMakeLists.txt :
cmake_minimum_required(VERSION 3.5) project(print_os_name) # Create a library add_library(get_os_library STATIC src/get_os_name.c) target_include_directories(get_os_library PUBLIC $/include) # Create an executable add_executable(print_os_name src/main.c) target_link_libraries(print_os_name PRIVATE get_os_library)
В данном примере будет две задачи: создание библиотеки и готовой программы.
Задача создания библиотеки создается функцией add_library . Первый ее аргумент – название задачи, обычно совпадающее с именем библиотеки. Далее указывается тип библиотеки (статическая), после чего указываются файлы исходных кодов.
Функция target_include_directories , как и в предыдущем примере, задает каталоги с заголовочным файлами. В отличие от предыдущего примера указывается область действия PUBLIC, чтобы подключить эти заголовочные файлы и ко второй задаче (создание программы).
Функция add_executable используется так же, как и в предыдущем примере.
Функция target_link_libraries подключает ко второй задаче библиотеку, создаваемую в первой задаче.
Соберите пример под Windows и под Linux (используя те же команды, что и в предыдущем примере).
Проверьте правильность работы программ.
Определите, какие файлы получились в результате выполнения каждой задачи под каждой ОС.
Попробуйте удалить файлы, полученные в результате выполнения задач по созданию библиотеки, и запустить программы без этих файлов.
Динамические библиотеки
Код функций из динамической библиотеки помещается в отдельный от программы файл. Функции из таких библиотек компонуются к основной программе во время работы программы (поэтому и называются динамическими). Достоинством динамических библиотек является возможность использовать их одновременно из нескольких программ (отсюда второе название – разделяемые (shared) библиотеки). Их недостаток – необходимость контролировать их наличие в операционной системе и версию.
Создайте новый каталог для изучения примера со статической библиотекой и скопируйте в него папки src и include вместе с файлами.
Добавьте в новый каталог файл CMakeLists.txt :
cmake_minimum_required(VERSION 3.5) project(print_os_name) # Extra lib files for WIN32 if(WIN32) set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) endif() # Create a library add_library(get_os_library SHARED src/get_os_name.c) target_include_directories(get_os_library PUBLIC $/include) # Create an executable add_executable(print_os_name src/main.c) target_link_libraries(print_os_name PRIVATE get_os_library)
Отличие конфигураций статически и динамически присоединяемых библиотек заключается в использовании ключевых слов STATIC и SHARED в функции add_library . Для Linux отличия заканчиваются.
Если сборка ведется под Windows (что проверяется командой if(WIN32) ), переменную CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS нужно установить в значение ON с помощью функции set . Это указывает cmake сгенерировать дополнительные файлы.
В Windows для создания программ, использующие динамические библиотеки, требуются дополнительные файлы для сборки программы. Код самих функций помещается в файлы с расширением .dll , которые используются во время работы. Во время сборки требуются файлы с описанием функций в файле .dll и кодом для доступа к этим функциям.
Соберите пример под Windows и под Linux (используя те же команды, что и в предыдущем примере).
Проверьте правильность работы программ.
Определите, какие файлы получились в результате выполнения каждой задачи под каждой ОС.
Определите, какие библиотечные файлы необходимы для запуска программ.
Источник: altmanea.ru
Кросс-компиляция и отладка C++ Windows-приложения под Linux
Показали мне недавно интересное приложение, под которое можно разрабатывать плагины. Приложение оказалось очень полезным для научной работы, но вот незадача — приложение разработано под Windows, у меня стоит Ubuntu. Windows для разработки под это приложение от лаборатории получить пока не удалось. Чтобы не тратить время, решил освоить кросс-компиляцию и отладку этого приложения.
Итого, имеется:
Ubuntu 12.10 x64
Не-юникодное приложение Мастерская Граф-Моделей (МГМ) (В командах консоли будет называться gmw.exe)
Нужно:
Разрабатывать и отлаживать плагины (dll-библиотеки), не устанавливая Windows.
И тут нам помогут Wine, Code::Blocks, портированное GDB, и boost.
Wine, не юникодное приложение, английский интерфейс Ubuntu и русский язык
При попытке открыть не юникодное приложение под Wine
wine gmw.exe
получаются зюки следующего вида:
На эту проблему интернет очень быстро дает следующую подсказку:
LC_ALL=ru_RU.UTF-8 wine gmw.exe
В моём случае, данный подход не улучшил ситуацию ни на йоту.
Как выяснилось, русских локалей в системе не было добавлено (тыц).
sudo echo «ru_RU.UTF-8 UTF-8» >> /var/lib/locales/supported.d/ru sudo locale-gen ru
Теперь запускаем с выше-указанной подсказкой
LC_ALL=ru_RU.UTF-8 wine gmw.exe
И, вуаля, запускается приложение с читаемым русским текстом:
Настройка IDE Code::Blocks для кросс-компиляции и отладки
Установка Code::Blocks
В дальнейшем для отладки нам потребуется менять код плагина отладки поэтому лучше сразу взять версию Code::Blocks из под svn.
Устанавливаем svn:
sudo apt-get install subversion
С помощью svn получаем код C::B, для этого переходим в папку, в которую хотим сохранить код C::B, где и набираем:
svn checkout svn://svn.berlios.de/codeblocks/trunk
Переходим в полученную папку ‘trunk’.
Компиляция C::B происходит с помощью g++, autotools, automake и некоторых других утилит, которые необходимо установить:
sudo apt-get install libtool autotools-dev automake autoconf g++ libhunspell-dev libgtk2.0-dev libgamin-dev libboost-dev
Кроме того Code::Blocks зависит от wxWidgets:
sudo apt-get install libwxgtk2.8-dev
Подстраиваем установщик под компьютер (можно запускать единожды):
sudo ./bootstrap
И дальше, устанавливаем сам codeblocks (ключ —prefix можно упустить для использования настроек по-умолчанию):
sudo ./configure —prefix= —with-contrib-plugins=all sudo make sudo make install
Более подробно можно посмотреть по ссылке.
Настройка компиляции и линковки
Выполняем пункты с 1 по 5 с форума Code::Blocks. После этого компиляция программ должна работать, если не используется линковка к платформо-зависмым библиотекам (линковка с boost::regexp будет рассмотрена позже).
(*) В новом Code::Blocks немного изменилось меню по сравнению с инструкцией. Настройки искать нужно в ‘Settings->Compiler. ‘. Для старого Code::Blocks (10.05) пункт 5 нужно выполнить полностью, для нового же (12.11) настройку касающуюся gdb в 5 пункте пока трогать не будем.
Если используется boost его лучше положить отдельно от /usr/include, т.к. по этому адресу лежит много linux-специфичных заголовочных файлов, которые мы не хотим включать в проект при компиляции под Windows.
UPD: При настройке линковки в поле «Other Linker Options» имеет смысл добавить опцию «-Wl,—subsystem,windows,—kill-at», которая помечает, что это реально Windows DLL, и, что самое главное, запрещает использовать декорирование символов (—kill-at) при экспорте функций с соглашением вызова __stdcall. Подрбнее здесь и здесь.
Начиная с пункта 7 по ссылке выше, описывается кросс-отладка, но, к сожалению, insight.exe, упоминающийся в инструкциях, найти не удается. Поэтому пойдем своим путем.
Кросс-отладка в Code::Blocks Debugger’ кликаем по ‘GDB/CDB debugger’ затем по ‘Create Config’. В новом конфиге меняем команду запуска отладчика на ‘/usr/bin/i586-mingw32msvc-gdb’, остальные настройки по желанию. После этого идем в ‘Settings->Compiler. «, в пункте ‘Selected Compiler’ выбираем тот компилятор, который настраивали до этого и затем на вкладке ‘Toolchain executables’ меняем ‘Debugger’ на наш свежесозданный конфиг. Теперь отладчик будет останавливаться на точках останова, хотя и остановить программу в произволльный момент не сможет (данная проблема пока еще не решена). Правда при попытке отладить,C::B выдает следующую ошибку:
The program has stopped on a breakpoint but the breakpoint format is not recognized: 0x1A0x1AZ:/SamplePlugin.cpp:48:948:beg:0x68087599
Эта ошибка говорит о том, что плагин отладчика в C::B не понимает выдачу отладчика gdb.exe. Как выяснилось при ближайшем рассмотрении плагин отладчика имеет платформо-зависимый код, и вот тут-то и нужно вспомнить что у нас есть исходники C::B. Мы сейчас слегка подкоррекируем код этого плагина. Нужно будет поменять код только одного файла ‘/src/plugins/debuggergdb/gdb_driver.cpp’
Для этого нужно перейти в корень проекта C::B (откуда запускалась команды ./bootstrap), по умолчанию это папка ‘trunk’. И накактить патч:
patch —unified —strip=0 —forward —input=gdb_driver.cpp.patch
Ну и пересобираем Code::Blocks:
sudo ./configure —prefix= —with-contrib-plugins=all sudo make sudo make install
И почти все готово, остается только создать проект. Шаги 12-13 по ссылке. Если же вы хотите создать проект dll-библиотеки, то указывайти создание динамической библиотеки в мастере и переименовывайте разширение в dll.
Проверям, что в настройках проекта стоит выбранная нами цепь компилятор-линкер-отладчик. ‘-Build Options. ‘ пункт ‘Selected compiler’, и можно радоваться и отлаживаться. Напомню, что по какой-то причине отладчик не может быть прерван во время исполнения, т.е. все отладочные действия могут буть применены только во время останова программы. В частности нельзя поставить новую точку останова, если программа не стоит на какой-либо другой точке останова…
Линкование статической библиотеки boost’а
Библиотека boost в основном является набором заголовочных файлов, и потому никаких проблем с линковкой обычно не возникает. Но для некоторых частей boost’а необходимо линковаться к статической библиотеке, например, boost::regex. Пробуем собрать проект и получаем:
/boost/regex/v4/cpp_regex_traits.hpp|1059|undefined reference to `boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex
Дальше настраиваем сборку и собираем:
sudo ./bootstrap.sh —with-libraries=regex —without-icu sudo ./b2
После выполнения последней команды у меня были ошибки «failed updating 1 target», что, правда, не мешает собираться программам.
В результате, у нас есть полностью подготовленная среда для написания, сборки и отладки Windows-приложений или Windows-библиотек из под Linux. Теперь можно приступать к работе…
Источник: habr.com
Qt WinAPI — Урок 003. Использование windeployqt для сбора DLL
А теперь приступим к работе с windeployqt . Допустим, у Вас уже имеется скомпилированный исполняемый файл и требуется собрать все необходимые для его работы DLL. Для этого сделаем небольшую подготовку и перекинем исполняемый файл в подготовленную для сбора папку. Я использую для демонстрации проект EColor , который написан с использованием MinGW. Исполняемый файл проекта будет размещён по следующему пути D:EColorEColor.exe.
После чего необходимо будет открыть консоль ( cmd ), и перейти в консоле в папку с windeployqt. Далее запускаем утилиту передав ей путь расположения исполняемого файла, как показано на нижеследующем рисунке.
После чего утилита соберёт все необходимые для работы исполняемого файла DLL-ки. А выглядеть это будет следующим образом.
Возможные ошибки
Также стоит отметить, что не всё может пройти достаточно гладко. Например, windeployqt, может не найти библиотеки компилятора gcc и выдать следующую ошибку:
Cannot find GCC installation directory. g++.exe must be in the system path.
Это лечится прописыванием в переменных среды пути к папке bin, которая содержит GCC и соответствующие библиотеки.
Для этого идём по следующему направлению (пример для ОС Windows 7 ):
Панель Управления / Система / Дополнительные параметры системы / Переменные среды
После чего добавим переменную PATH в системные переменные, где будут прописаны пути к GCC и его библиотекам. В моём случае это выглядело так:
- Имя переменной: PATH
- Значение переменной: D:AndroidQTQT5.5mingw492_32bin;D:AndroidQTQTToolsmingw492_32bin;%PATH%
После чего рекомендую перезагрузить ПК. После этого ошибка должна будет пропасть, а соответствующие библиотеки должны будут подтянуться в папку с исполняемым файлом.
Файлы, которые могут быть не собраны windeployqt
Также, некоторые файлы могут быть не собраны с помощью windeployqt , что стоит также учесть и протестировать приложение на другом ПК перед выпуском.
К примеру при сборке DLL для EColor, windeployqt всё-таки пропустила следующие файлы:
- LIBEAY32.dll
- MSVCP90.dll
- MSVCR90.dll
- MSVCR120.dll
- ssleay32.dll
Если проект с использованием QML
Если в проекте используется QML, то необходимо добавить специальную директиву —qmldir
Данная директива должна будет указать откуда брать исходники QML
windeployqt —qmldir f:myAppsources f:build-myAppmyApp.exe
Видеоурок
Рекомендуем хостинг TIMEWEB
Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.
Рекомендуемые статьи по этой тематике
- Qt/C++ — Урок 056. Подключение библиотеки Boost в Qt для компиляторов MinGW и MSVC
- Qt/C++ — Урок 025. Создание проекта файлов для сборки утилитой qmake
- Qt WinAPI — Урок 001. Как собрать все DLL, используемые в Qt-проекте?
По статье задано0 вопрос(ов)
Подписка на обсуждение 3
Подписка на раздел 334
Вам это нравится? Поделитесь в социальных сетях!
Источник: evileg.com