Использование научной библиотеки GNU (GSL) под Windows x64 с MinGW

Я установил MinGW и MSYS в Microsoft Windows (64-разрядная версия) внутри каталога C:\MinGW (каталог MSYS — C:\MinGW\msys\1.0). Я загрузил последний пакет научной библиотеки GNU (GNU GSL) с официального ftp.

Я использовал MSYS для успешного выполнения configure и make, как описано в файле INSTALL в пакете GSL. Это означает, что в интерфейсе командной строки MSYS в каталоге MSYS home я вставил:

$ ./configure
$ make
$ make install

Это создает каталог local в каталоге MSYS (C:\MinGW\msys\1.0), включая каталоги bin, include, lib и share.

Я успешно скомпилировал пример программы ( который вычисляет значение функции Бесселя $J_0(x)$ при $x = 5$) в соответствии с инструкциями в Руководство по GSL, автор

$ gcc -Wall -I/usr/local/include -c example.c

В результате получается объектный файл example.o, как и ожидалось, без каких-либо сообщений об ошибках.

Объектный файл связан в соответствии с инструкции от

$ gcc -L/usr/local/lib example.o -lgsl -lgslcblas -lm

Это создает исполняемый файл a.exe, который можно запустить в среде MSYS. Однако в интерфейсе командной строки Windows cmd.exe при попытке запустить исполняемый файл появляется следующее сообщение об ошибке:

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

Интересно, чего не хватает? Что нужно сделать, чтобы создать исполняемый файл?


windows linker-errors mingw gsl
person AlQuemist    schedule 03.05.2015    source источник

Ответы (5)


arrow_upward
7
arrow_downward

Когда вы создаете проекты для MinGW, в MSYS вы должны всегда указывать аргумент --prefix для ./configure; (по умолчанию /usr/local указывает путь, специфичный для MSYS, который совершенно не подходит для разработки приложений MinGW). В вашем случае вы должны были настроить GSL следующим образом:

./configure --prefix=C:/MinGW

или, что еще лучше, отделите файлы сборки от исходников (например, в виде подкаталога верхнего исходного каталога GSL):

mkdir build
cd build
../configure --prefix=C:/MinGW

Это гарантирует, что все библиотеки и заголовочные файлы, установленные пакетом, будут расположены в соответствующих каталогах, где их может найти MinGW, и, что более важно, там, где установленные библиотеки DLL будут найдены с помощью поиска %PATH% при работе вне MSYS.

Настроив так, как вы это сделали, когда вы впоследствии запустили

make
make install

вы установили библиотеки и заголовки MinGW для использования MSYS (что неверно), и, в частности, libgsl-0.dll будет установлено в C:/MinGW/msys/1.0/local/bin, тогда как оно должно быть в C:/MinGW/bin (именно здесь последний команда должна установить его, следуя конфигурации с соответствующей спецификацией --prefix=C:/MinGW).

Важная сноска

Следует отметить, что предыдущая процедура правильно подготовит GSL (или любую другую библиотеку, подготовленную аналогичным образом) для использования с MinGW и позволит вам запускать приложения, которые вы связали с такими библиотеками, на хосте разработки (или на любом другом хосте с аналогичной установкой MinGW). Однако, если вы хотите распространять такие приложения (и при условии, что вы соблюдаете какие-либо условия лицензирования), чтобы их можно было запускать как автономные приложения (т. е. без требования, чтобы MinGW был установлен на компьютере конечного пользователя), вы должен позаботиться о том, чтобы в вашем дистрибутиве были должным образом удовлетворены зависимости времени выполнения. Чтобы достичь этого, вы должны выбрать:

  1. Свяжите приложение статически. Это может быть уместно, если ваш дистрибутив ограничен одним или, может быть, двумя исполняемыми файлами, но быстро приведет к «раздуванию исполняемых файлов» по ​​мере увеличения количества исполняемых файлов с общей зависимостью базовой библиотеки в наборе распространяемых приложений. В последнем случае лучшим выбором будет
  2. Связывайте приложение динамически и распространяйте копии всех необходимых библиотек DLL (кроме системных библиотек DLL) вместе с набором приложений; в этом случае вы не должны делать никаких предположений относительно макета каталога или %PATH% настроек, которые могут применяться или не применяться на компьютере конечного пользователя; вы должны просто упаковать свой дистрибутив так, чтобы все поставляемые исполняемые файлы и сопровождающие их библиотеки DLL были установлены в один и тот же каталог.
person Keith Marshall    schedule 04.05.2015
comment
Спасибо за подробный ответ, @Keith Marshall. С предложенной вами конфигурацией я теперь могу легко скомпилировать в Windows cmd с g++ -c example.c -o example.o, а затем связать с g++ example.o -lgsl -lgslcblas -lm. Сообщения об ошибках не появляются. - person AlQuemist; 05.05.2015

arrow_upward
4
arrow_downward

Для справки отмечу, что все предыдущие ответы устарели. Для Win64 MinGW и MSYS были заменены независимыми проектами Mingw-w64 и MSys2. И больше не нужно компилировать GSL самостоятельно: используйте бинарники с https://packages.msys2.org/package/mingw-w64-x86_64-gsl.

person Joachim W    schedule 12.07.2020

arrow_upward
1
arrow_downward

Я нашел также частичное решение; но я точно не знаю, почему это работает!

С помощью той же процедуры и конфигурации, о которых я упоминал изначально в вопросе, если кто-то использует Windows cmd (CLI) и компилирует и связывает код C (example.c) с

gcc -c example.c -I"C:\MinGW\msys\1.0\local\include" -Wall
gcc -static example.o -L"C:\MinGW\msys\1.0\local\lib" -lgsl -lgslcblas -lm

или код C++ (эквивалентный example.c) с

g++ -c example.cpp -I"C:\MinGW\msys\1.0\local\include" -Wall
g++ -static example.o -L"C:\MinGW\msys\1.0\local\lib" -lgsl -lgslcblas -lm

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

Пожалуйста, поправьте меня, если я ошибаюсь.

person AlQuemist    schedule 05.05.2015
comment
В некотором роде это работает, смягчая симптомы проблемы, а не устраняя ее причину; как таковой, это скорее (принципиально неудовлетворительный) обходной путь, чем фактическое решение. - person Keith Marshall; 06.05.2015
comment
Чтобы уточнить: основная проблема, причина, заключается в том, что библиотеки и заголовки были установлены в неподходящем месте. Это приводит к симптомам, заключающимся в том, что эти библиотеки и заголовочные файлы труднее найти во время сборки, а общие объекты (DLL) не обнаруживаются во время выполнения. Вы устранили первый симптом, указав явные -I path/to/headers и -L path/to/libraries во время сборки. Вы смягчили второе, установив статическую компоновку, поэтому теперь во время выполнения нет зависимости от DLL, но в результате ваш исполняемый файл стал излишне раздутым. - person Keith Marshall; 06.05.2015
comment
В качестве последнего уточнения: проблема не столько в динамическом связывании, сколько просто в том, что вы можете смягчить симптом фундаментальной проблемы во время сборки, но, если вы продолжите динамически связывать, вы не сможете смягчить размещение требуемой библиотеки DLL в каталоге, где никакое родное (MinGW) приложение никогда не должно ее искать; вы можете исправить это, установив соответствующий префикс, такой как C:/MinGW, тогда как /usr/local (обычный пакет GNU по умолчанию) не подходит для приложений, созданных MinGW, и их вспомогательных библиотек. - person Keith Marshall; 06.05.2015

arrow_upward
0
arrow_downward

Исполняемый файл не запускается под Windows cmd, поскольку скомпилированная библиотека libgsl-0.dll отсутствует в системном или пользовательском пути. Windows не знает, где его искать. Немедленное решение состоит в том, чтобы сообщить системе, где ее найти, отредактировав переменную среды PATH, включив в нее расположение libgsl-0.dll. Это можно сделать с помощью cmd, введя

PATH=PATH;path-to-libgsl-0.dll

в командной строке. (Я точно не помню, где заканчивается библиотека, поэтому, пожалуйста, простите меня за неточность.) Однако это будет длиться только в течение сеанса, и чтобы сделать изменение постоянным, необходимо отредактировать переменную PATH, пройдя через панель управления. . Один из способов доступа к переменным среды — щелкнуть «Дополнительные параметры системы», которые можно найти слева в окне, выбрав «Панель управления» -> «Система и безопасность» -> «Система» или щелкнув правой кнопкой мыши «Компьютер» в меню «Пуск». Меню и выбрав Свойства. При нажатии на «Дополнительные параметры системы» открывается окно, в котором отображается кнопка «Переменные среды», и переменные среды становятся доступными при нажатии на эту кнопку. Однако для редактирования PATH я бы рекомендовал использовать бесплатную утилиту PathEditor.exe, которую можно найти здесь . Эта утилита значительно упрощает процесс.

Однако ваши настройки сборки далеки от оптимальных. Использование шага .configure без каких-либо параметров означает, что сгенерированные файлы будут установлены в папку C:\MinGW\msys\1.0\local и распределены по нескольким каталогам. Будет сложно удалить файлы, если вы захотите установить более новую версию GSL после установки других библиотек разработки. Я бы рекомендовал добавить опцию --prefix=C:/MinGW/gsl к шагу .configure. (Чтобы получить полный набор опций, запустите .configure --help.) Это позволяет очень легко отменить установку, если это необходимо, просто удалив или переименовав C:\MinGW\gsl. Кроме того, целью MSYS является облегчение создания программного обеспечения, предназначенного для систем GNU, что не является способом Windows. Созданное программное обеспечение должно находиться не в MSYS, а где-то в C:\MinGW и быть доступным для инструментов сборки в C:\MinGW\bin, которые используются для создания собственных программ Windows с использованием cmd или других подходящих инструментов Windows. На практике это означает, что всегда следует использовать --prefix=C:/MinGW, если MSYS требуется для создания программного обеспечения, которое будет использоваться в MinGW, как в этом случае заголовочные файлы и библиотеки GSL. Однако предпочтительно по указанным причинам выбрать --prefix=C:/MinGW/software.

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

person gostal    schedule 15.06.2016

arrow_upward
0
arrow_downward

Это не так просто. gcc запускается из командной строки LINUX в ​​оболочке bash. MinGW32-gcc запускается из командной строки DOS в оболочке cmd.exe. Динамическая компоновка, необходимая для выполнения программы, для которой требуется библиотека динамической компоновки (.dll в DOS или .so .la в Linux), также зависит от ОС. Динамические библиотеки Linux и динамические библиотеки Windows не являются взаимозаменяемыми. Так много ожидается; однако статические библиотеки, созданные gcc и ld в оболочке bash Linux, кажутся несовместимыми с MinGW32-gcc в оболочке cmd.exe Windows, и это меня удивляет. Я не могу заставить MinGW32-gcc ссылаться на libgsl.a; Я продолжаю получать неразрешенные ссылки от ld. Я также не могу понять, как заставить GSL встроиться в оболочку cmd.exe.

person Byron    schedule 28.09.2016