Сборка Mingw - зависит от DLL не родной для Windows

Question

Я компилирую свою библиотеку для экспорта как общую библиотеку, используя MinGW (GCC 4.5.0).Я делаю это, компилируя все исходные файлы, используя команды MAKE, подобные:

gcc -shared -c mysource.cpp -o mysource.o

И, наконец,:

gcc -shared -lstdc++ -lm -lws2_32 mysource.o -o mylib.dll

Когда я выполняю обход зависимостей моего выходного файла (используя http://www.dependencywalker.com/ например), я вижу, что есть 3 зависимости:

KERNEL32.dll
MSVCRT.dll
LIBSTDC++-6.DLL

Наличие моей DLL зависит от файлов, которые не поставляются с окнами, является неоптимальным для моей конечной цели.

Есть ли способ настроить мою систему так, чтобы конечный вывод (DLL) ONLY зависел от KERNEL32 и MSVCRT ?

Answer 1

Флаг -static может быть тем, что вы ищете. (Мне все еще кажется странным использовать -static и -shared в одной строке, но они не противоположны.)

Если бы вы использовали g++ в качестве драйвера вместо gcc, вы могли бы вместо этого использовать флаг -static-libstdc++.

Answer 2

Что ж, это именно то, что вы сказали своему компоновщику делать с -lstdc++ ... возможно, переместите этот параметр до -shared и выполните ссылку снова. Насколько мне известно, тогда следует использовать статическую версию стандартной библиотеки C ++.

Примечание: я думаю, что была и хорошая причина предпочесть g ++ для целей C ++ вместо использования gcc. Вероятно, речь шла о включении стандартной библиотеки C ++. Не могу вспомнить это из головы. Кроме того, я не знаю, отличается ли MinGW в этом случае.

Answer 3

Я верю, что правильный ответ - «НЕТ». Другие люди, отвечающие на это, не пытались решить вашу проблему. Я был бы рад показать, как я ошибаюсь, но я исчерпывающе исследовал это, и как минимум среды MINGW и CYGWIN, похоже, требуют распространения с динамически связанной библиотекой Windows (dll).

Для Cygwin64 я компилирую, используя "g ++" с этими флагами:

FFLAGS = -g -Wunused-variable -static -static-libgcc -static-libstdc++

но исполняемый файл все еще требует распространения с "cygwin1.dll" - я очень согласен, что это неоптимально, и я не понимаю ограничения. Я нашел похожие проблемы в MINGW.