О кросс-платформенной компиляции для новичка

1. Поищи их в инсталяции MinGW, должны быть в каталоге bin. Их надо либо положить в каталог с ехе либо прописать в путях(тут я могу ошибаться). Можно слинковать их статически -static-libgcc -static-libstdc++

2. В общем случае - да

3. Я очень сильно сомневаюсь что удастся собрать исполняемый файл для linux из под виндов. Проще будет из под линукса собирать для него и для винды (для кросс-компиляции гугли про MXE и подобное). И на обоих системах ты получишь проблемы, когда на машине пользователя не окажется нужных библиотек.

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

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

2. Если хочешь посмотреть, как это все выгдялит под Linux - поставь себе Linux (https://getfedora.org/, например) в VirtualBox и скомпилируй в виртуалке свое приложение.

Какие зависимости могут быть в линуксе? Как предусмотреть эти зависимости?

В ляликсе есть замечательная комманда ldd, которая покажет требуемые зависимости для запуска приложения.

janb@janb-xbnt ~/data/work/m32_plot_proj/build_pc_debug $ ldd m32_plot 
	linux-gate.so.1 =>  (0xb7797000)
	libQt5Widgets.so.5 => /usr/lib/i386-linux-gnu/libQt5Widgets.so.5 (0xb7025000)
	libQt5Gui.so.5 => /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5 (0xb6a96000)
	libQt5Core.so.5 => /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5 (0xb6556000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb6461000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6444000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6289000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb626c000)
	libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb620e000)
	libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb60e6000)
	libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb5f9b000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb5f4e000)
	libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb5f22000)
	libharfbuzz.so.0 => /usr/lib/i386-linux-gnu/libharfbuzz.so.0 (0xb5ec3000)
	libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb5ea8000)
	libGL.so.1 => /usr/lib/i386-linux-gnu/mesa/libGL.so.1 (0xb5dfa000)
	libicui18n.so.52 => /usr/lib/i386-linux-gnu/libicui18n.so.52 (0xb5bda000)
	libicuuc.so.52 => /usr/lib/i386-linux-gnu/libicuuc.so.52 (0xb5a59000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb5a53000)
	librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb5a4a000)
	/lib/ld-linux.so.2 (0xb7798000)
	libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb5a40000)
	libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb59ce000)

https://www.ibm.com/developerworks/ru/library/l-lpic1-v3-102-3/

и на линуксе (макос, проч.)

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

Для начала скомпилил хелловорд. Не запускается - требует libgcc_s_dw2-1 и libstdc++-6.

покажи helloword.cpp и Makefile. Если и впрямь собрался, но при выполнении хриплокричит про недостаток либ - надо смотреть что с путями и где те либы

В ляликсе есть замечательная комманда ldd, которая покажет требуемые зависимости для запуска приложения.

в винде она тоже есть. в MSYS2.

2. Зависимости - это речь только о библиотеках?

в баше:

export a='s/C:\\/\/c\//g' b='s/D:\\/\/d\//g'`
export c=`echo $SYSTEMROOT|sed -e $a -e $b`
ldd ./hello.exe |grep -iv $c

всё что увидишь — это зависимости, которые нужно тянуть рядом с hello.exe, или устанавливать нормальным инсталлятором (в системные библиотеки).

инсталлятор также понадобится чтобы доустановить зависимости (их инсталлятором), зарегестрировать COM сервера, добавить ярлык в кнопку пуск, прописать переменные окружения, добавить в PATH.

изучай программы для создания инсталляторов: NSIS , InstallShield.

Для начала скомпилил хелловорд. Не запускается - требует libgcc_s_dw2-1 и libstdc++-6.

вот именно поэтому C++ сосёт. в plain C зависимости более минимальны, в C++ этот ненужный рантайм на 800К минимум.

если ты напишешь на plain C получишь 0 зависимостей от рантайма и 20Кб .exe после strip.

также изучай статическую и динамическую сборку (g++ -static, g++ -Bdynamic).

вообще MinGW под виндой сосёт (иногда падает с error: no error, лол) и лучше использовать кросскомпиляцию из линукса, там оно как-то поштабильнее будет, со швободкою-то.

см. например mxe.cc про кросскомпилятор из линуха в винду. также в Gentoo например можно установить crosstools и собирать cross emerge.

если кросскомпилировать из винды в линукс, то примерно также всё будет: собрать кросс gcc из под mingw в линукс, изменять название кросс gcc, собирать с CC=cross-gcc make install.

но проще кросскомпилировать из линуха в винду, там оно и постабильнее будет. как — см. тот же проект mxe.cc, например.

3. Как происходит компиляция в исполняющий файл в случае, если его хочешь запускать и на линуксе (макос, проч.)?

разными кросскомпиляторами: указываешь разные cross-gcc в CC=cross-gcc make install. То есть, собираешь три раза в разные системы, с make DESTDIR разными (ну или через --prefix для configure, указывашь разные пути).

Какие зависимости могут быть в линуксе?

читай про Linux Standard Base и кроссдистрибутивность.

Как предусмотреть эти зависимости?

по нормальному, ты должен написать свой инсталлятор, под свой пакетный менеджер. конкретного дистрибутива.

или собирать статически.

Как предусмотреть эти зависимости? Никак, только с помощью сообщений от ОС, что «не могу запустить, потому что нет такой-то библиотеки»?

пиши враппер запускалка.sh которая запускает запускалку.bin с нужными LD_PRELOAD.

ещё в винде есть ntldd.

ещё есть библиотека U++, например (Ultimate++). хотя С++ и сосёт.

Подтверждаю, из-под линукса легче делать под винду. Ещё потому что есть wine.

Но в любом случае для чего-то более-менее крупного придётся держать виртуалки.

Это не все зависимости. Забыл про /usr/lib/i386-linux-gnu/qt5/plugins/platforms/libqxcb.so и иже с ними, которые через dlopen и аналоги работают.

если ты напишешь на plain C получишь 0 зависимостей от рантайма и 20Кб .exe после strip.

Нет. Он получит также зависимость от libgcc_s_dw2-1 и 100-200 КБ .exe после strip и -static-libgcc.

А потому что MinGW и винда. Только в штудии можно получить маленький exe и минимум зависимостей при Pure C.

Нашел в bin.
Вариант прописать в системных переменных путь к bin не подходит, т.к. теряется вин-кроссплатформенность - на другую вин-машину не передать. Либо делать еще и инсталлятор.
Вариант держать эти библиотеки в папке с exe - не работает.
Вариант встроить - сделал, но блин тут же раздулся от кб до 1.2 метров. Либо опять делать инсталлятор.

Прописал в системный путь:
g++ D:\TESTPROJ\one\main.cpp -o main.exe -static-libgcc -static-libstdc++

Пробовал:
g++ D:\TESTPROJ\one\main.cpp -o main.exe -Bdynamic-libgcc -Bdynamic-libstdc++
Размер уменьшился опять до кб, рядом этих dll не появилось. Что должно было произойти?

#include <iostream>

using namespace std;

int main()
{
    cout << "Say a word: " ;
    string word;
    cin >> word;
    return 0;
}

Makefile нет - Code::Blocks не создает, а вручную не умею.

Пример: пользуюсь stl, boost, wxWidgets.
Правильно ли я понял, что в таком случае зависимости будут для кода:
1.который лежит в .lib (.o), .dll (.o). Например, функции либо классы математических операций и т.п.
2. классы либо функции самой целевой ОС. 3. Погуглил, эти dll нужны компилятору. От компилятора тоже какие-то зависимости могут быть? Он же в машинный код все транслирует, там уже ничего не остается.

в системных путях должен быть прописан путь к библиотекам MinGW.

См. инструкцию по установке MinGW (да читайте-же наконец-то эти чёртовы man`ы)

ps. Лучше осилить самому писать Makefile - от CodeBlocks останется только редактор (не из лучших) и отладчик

Вариант держать эти библиотеки в папке с exe - не работает.

Что за бред? Чем это не работает?

Вариант встроить - сделал, но блин тут же раздулся от кб до 1.2 метров. Либо опять делать инсталлятор.

Для standalone, portable приложения статическая линковка единственное вменяемое решение. В другом случае — инсталлятор.

но блин тут же раздулся от кб до 1.2 метров.

Оно и так и эдак будет раздутым, что при динамической линковке (тянуть dll на несколько МБ), что при статической. Хоть ты тресни.

1.который лежит в .lib (.o), .dll (.o). Например, функции либо классы математических операций и т.п.

Зависимости от внешних библиотек характеризуются тем, как эти внешние библиотеки собраны. Если они собраны в *.lib (в случае с MinGW *.a), то это статические библиотеки, которые вкомпиливаются внутрь твоего *.exe файла. Если в *.dll, то в динамические, которые будет требовать твой *.exe при запуске.

boost, wxWidgets и даже stl это нестандартные библиотеки Windows, а следовательно за их распространением должен следить лично ты. Либо вкомпиливать их статически в исполняемый файл, получая на выходе больших размеров *.exe, либо в папочке рядом с *.exe класть все необходимые *.dll. В случае с MinGW кроме boost'а и wxWidgets нужно будет положить libgcc_s_dw2-1, libstdc++-6 и если в приложении используются потоки, libwinthread. В случае с Visual Studio придётся поставлять библиотеки времени исполнения MS Visual C++ (msvcrtXXX.dll и другие).

2. классы либо функции самой целевой ОС.

Классы либо функции целевой ОС даёт тебе WinAPI и более высокоуровневые прослойки над ним.

3. Погуглил, эти dll нужны компилятору. От компилятора тоже какие-то зависимости могут быть? Он же в машинный код все транслирует, там уже ничего не остается.

Бред какой-то про машкод. Конечно, от неродного в MS Windows компилятора MinGW будут зависимости в виде той же libgcc_s_dw2-1 и собственно, stl — libstdc++-6. Если компилить MS Visual Studio, то тоже будут зависимости от постоянно обновляющихся Runtime-библиотек C и C++.

Настоятельно рекомендую разобраться с азами компиляции и мануалами к компиляторам. А уж потом писать приложение.

Работаю на винде

Не работай на венде, уважай себя. Если хочешь быстро, беспалевно и без SMS — накати арчик без иксов в виртуалку, свежий кросс-компилятор под венду с сопутствующим рантаймом в комплекте.

Далее, есть MinGW, а есть MinGW-w64. Это разные проекты. Не вдаваясь в подробности: MinGW ­­­— сосёт и вообще сдох. Розовые сопли участников — игра по «правилам» (никакого реверс-инжиниринга, только «фицияльная» документация), ребята забыли что M$ это не *та* контора с которой можно играть по правилам — привели к стагнации проекта.

Для тех кому хочется крикнуть «Рач!», напомню, что обычно MinGW-w64 под венду грокается в составе Msys2 (не путать с просто Msys), а пакетный менеджер там, правильно, pacman.

libgcc — вспомогательная библиотека компилятора GCC (всякая низкоуровневая и неинтересная хрень), вообще-то должна линковаться статически.

libstdc++ — стандартная библиотека C++.

Добавь каталог с компилятором в PATH, и будет тебе счастье. Для передачи «во вне», тебе всё-равно линковать только статически. Опен-сорс проекты никогда не были избалованы нахождением в венде по дефолту, типа как стандратной библиотеки C++ за авторством M$.

Ну, и бинарники на C++ несовместимы между GCC и MSVC, т.е. если у тебя есть DLL, скомпилированная MSVC, то из программы, скомпилированной на GCC ты её использовать не сможешь (и наоборот). К просто C это, ясен пень, не относится.

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

И да, IDE — абсолютное зло. На первых порах, только текстовый редактор и командная строка. Придётся изучать принципы работы компилятора и линковщика и их параметры (хватит на два космических корабля).

Вариант встроить - сделал, но блин тут же раздулся от кб до 1.2 метров.

А ты как хотел? Есть ещё команда strip (или опция -s), которая уменьшит размер бинарника... Но лучше *так* не делать.

Ты думаешь что полностью статическая версия у MSVC получится меньше? Хренушки. Скажи ещё спасибо, что используется системная версия сишного рантайма, сиречь mscrt.dll, а то размер был бы ещё больше.

Есть ещё премерзкое поведение бинутилзов под венду (точнее под COFF/PE), при котором образуется мусор в .rdata. В общем, собрать нормальный бинарник под венду — та ещё задачка... И пока не прокачаешь скиллы, лучше юзать статическую линковку.

Вариант держать эти библиотеки в папке с exe - не работает.

Это с какого ещё перепугу? Всё прекрасно работает, это практика освящённая десятилетиями.

теряется вин-кроссплатформенность - на другую вин-машину не передать

Ну это называется не кроссплатформенность.

Вариант держать эти библиотеки в папке с exe - не работает.

Работает. Где-то ты накосячил.

Либо делать еще и инсталлятор.

Нормальный вариант. Под винду можешь взять какой-нть Inno Setup, он бесплатный и работает на скриптах. Ну а под линукс таких проблем нет, просто включи в свой RPM/DEB нужные зависимости.

Вообще, если хочешь свести к минимуму проблемы с адаптацией на другие ОС - лучше писать под линуксом, а потом собирать под виндой. Шанс, что после этого под виндой заведётся с полпинка, 99%. А вот если разработку ведёшь под виндой - очень может быть так, что ты вместо #include <math.h> напишешь #include <Math.h>, и будешь долго удивляться, что линуксовый компилятор ругается, хотя виндовый всё отлично собирал. Из распространённых ОС только у одной имена файлов регистронезависимы, и это была бы её проблема, но к сожалению, ОС эта называется Windows.

Как происходит компиляция в исполняющий файл в случае, если его хочешь запускать и на линуксе (макос, проч.)?

Под линукс, макось и винду бинарники всё равно будут разные. И лучше всего собирать каждый под «родной» ОС. Хотя сборка под винду в линуксе более-менее хорошо описана в интернете, да и в этой теме упоминалась.

И имей в виду: никакая кроссплатформенность не избавит тебя от необходимости тестировать каждую сборку на своей целевой платформе: виндовую на винде (может, даже на нескольких версиях), линуксовую на линуксе (тут надо смотреть, какие дистрибутивы должны поддерживаться) и др. Мне в этом плане легче: я на работе могу себе позволить писать под линуксом, а вендосборку и её тестирование поручить молодому коллеге. (Ещё лучше, когда в проекте есть отдельные штатные тестировщики.) Если у тебя такой возможности нет - приготовься держать несколько виртуалок на машине, для разработчика переносимого ПО это абсолютно нормальная практика.

Что за бред? Чем это не работает?

hobbit[/]

Работает. Где-то ты накосячил.

Не проверил( Положил свой .cpp и эти .dll водну папку и скомпилил g++. Ошибок не выдал, но я и не стал проверять на другой вин-машине, потому что читал, что для связи своей с .dll нужен еще и ее заголовочный .h-файл, чтобы из кода можно было вызывать функции в .dll. Теперь проверил на другой вин-машине - все работает. Получается, .h-файл не нужен?

Значит получается, мне нужно:
1. Поставить линукс.
2. Научиться собирать через makefile.

С созданием makefile'ов буду гуглить. А по поводу линукса какой посоветуете? Упоминали и ArchLinux, и Fedora. Ставил себе только убунту (не надолго). Или без разницы? Тут еще нюанс (а может и нет) - еще интересно запилить на Steam.

И, если я верно понял, мне не предусмотреть заранее, какие зависимости будут у моего кода на разных платформах? Заведомо известные зависимости - это рантайм-библиотеки каждой платформы и те библиотеки, которые буду использовать (boost, stl, wxWidgets, qt, sdl2 и т.п.)?

Не проверил после компиляции. Думал, к .dll нужен его заголовочный файл.

Упоминали и ArchLinux, и Fedora. Ставил себе только убунту (не надолго). Или без разницы?

Без разницы. Это уже тараканы в их головах говорят тебе ставить их любимый дистрибутив.

С созданием makefile'ов буду гуглить.

Лучше сразу гугли CMake. Оно кросплатформенно (под Шin даже GUI есть) и будет создавать тебе Makeфайлы автоматически со всеми зависимостями и довольно простое в освоении.

Ошибок не выдал, но я и не стал проверять на другой вин-машине, потому что читал, что для связи своей с .dll нужен еще и ее заголовочный .h-файл, чтобы из кода можно было вызывать функции в .dll

Что-то у вас кашка в голове. Советую вам прочитать какую-нибудь книгу по компиляции. Из того, что помню — «GCC: Настольная книга пользователей, программистов и системных администраторов.» Или «GCC. Полное руководство.».

Ну и мануалы по MinGW.

Думал, к .dll нужен его заголовочный файл.

GCC (точнее, binutils) умеет использовать DLL (SO под линуксом) напрямую. Удобно.

На тех системах, где целевой DLLки по каким-то причинам нет, нужна специальная библиотека-заглушка. Она генерится либо при сборке DLL, либо *из* DLL.

код может быть кроссплатформенным, по большей части (и то чаще всего обрастает ifdef'ами). но, в конечном итоге, под каждую систему его лучше собирать в родном окружении. потому что везде свои тараканы, а юзер хочет получить работающее приложение из коробки. то есть, с инсталлятором и без дополнительного геморроя с притягиванием лишних зависимостей.
кроссплатформа из-под венды в линь - вещь возможная, но зело геморно. в обратную сторогу гораздо проще, под линём кросскомпилировать под другие системы.
могу посоветовать ресурс про кроссплатформенное программирование crossplatform.ru. там навалом и документации, и форум с кучей вопросов конкретно по кроссплатформе, и про сборки под вендой в том числе. а здесь венда оффтопик и вряд ли что посоветуют. я сама давно уже с вендой дел не имею, но кое-что ещё помню, со старых времён.

А по поводу линукса какой посоветуете?

Вообще-то правильный ответ - «тот, по которому у тебя есть знакомый гуру». Убунту не такой плохой выбор, но у неё есть обратная сторона - за вшитую поддержку большого количества разнообразного железа приходится платить, и в итоге это не самый маленький и не самый быстрый дистрибутив. Думаю, Арч и Генту на первых порах не стоит, можно посмотреть на Минт, Федору, отечественный ROSA Fresh. Сам сижу на дебиане, по мне так вполне беспроблемная вещь (SteamOS основан на дебиане, если что), но те, кто его ставил на ноутбуки, жалуются на сложность установки Wi-Fi. Пару лет назад очень хорош был openSUSE (12.2), но в последних версиях что-то напакостили с мультимедией, и теперь, чтобы что-то посмотреть-послушать, даже при подключённых дополнительных репозитариях надо трясти с бубном.

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

Плюсую, и не только собирать, но и тестировать.

потому что читал, что для связи своей с .dll нужен еще и ее заголовочный .h-файл, чтобы из кода можно было вызывать функции в .dll

Читал ты, скорее всего, правильно, но не понял контекст. Для сборки программы, которая эту DLL использует - да, нужен. Для запуска - нет.

Лучше сразу гугли CMake

Погуглил. На стековерфлоу сказали, что использовать для кроссплатформы. Углубляться в причины не стал - и так сойдет:)

«GCC: Настольная книга пользователей, программистов и системных администраторов.» Или «GCC. Полное руководство.».

Спасибо. Нашел, почитал. Начало - то, что надо. Дальше - пока рановато.

но, в конечном итоге, под каждую систему его лучше собирать в родном окружении.

Разрабатываю в линуксе, компилю в каждой целевой платформе. Интересуюсь геймдевом. Интересный подход нашел у Godot (типа юнити, но опенсорс под MIT): скриптовый код работает через плеер, который состоит из скомпилированных библиотек под платформы. Не знаю пока как на практике, но собирать на других платформах не надо - на своей, на которой разрабатываешь, подцепляешь библиотеки мака, например.

ресурс про кроссплатформенное программирование crossplatform.ru.

Спасибо!

Минт

Как-то тоже его ставил. Приятный гуи, про стабильность, удобство разработки и поддержку железа (у меня принтер, вай-фай свисток и встроенная видюха) - не знаю. Ну и разработка под стим интересна, а официально они только убунту поддерживают. Поэтому пока не уверен, что ставить.

Для сборки программы, которая эту DLL использует - да, нужен. Для запуска - нет.

Ясно( Спасибо.