LINUX.ORG.RU

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

 , ,


1

3

Работаю на винде. Цель: исполняемая программа для Win, Linux. Инструменты: MinGW и Code::Blocks.

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

Вопросы: 1. Что это за библиотеки, кто знает? Они нужны только в винде или на линуксе тоже?

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

3. Как происходит компиляция в исполняющий файл в случае, если его хочешь запускать и на линуксе (макос, проч.)? Какие зависимости могут быть в линуксе? Как предусмотреть эти зависимости? Никак, только с помощью сообщений от ОС, что «не могу запустить, потому что нет такой-то библиотеки»?



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

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

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

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

Vinick ★★
()

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

slovazap ★★★★★
()

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

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

anonymous
()

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

В ляликсе есть замечательная комманда 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/

JANB
()

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

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

sT331h0rs3 ★★★★★
()

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

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

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

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

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

anonymous
()

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.

anonymous
()

Для начала скомпилил хелловорд. Не запускается - требует 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, например.

anonymous
()

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

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

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

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

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

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

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

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

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от Vinick

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

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

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

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

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

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

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

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

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

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

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

Прописал в системный путь:
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 не появилось. Что должно было произойти?

nevro
() автор топика
Ответ на: комментарий от MKuznetsov
#include <iostream>

using namespace std;

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

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

nevro
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

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++.

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

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

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

Не работай на венде, уважай себя. Если хочешь быстро, беспалевно и без 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 — абсолютное зло. На первых порах, только текстовый редактор и командная строка. Придётся изучать принципы работы компилятора и линковщика и их параметры (хватит на два космических корабля).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

hobbit ★★★★★
()

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

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

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

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

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

hobbit[/]

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

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

nevro
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!

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

Минт

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

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

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

nevro
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.