Проблемы GCC/MinGW с GSL

Я пытаюсь скомпилировать C-программу с использованием MinGW в Windows 7. Программа использует CBLAS-библиотеку GSL, поэтому, короче говоря, я (пытаюсь) запустить эту команду в терминале (cmd):

gcc MyProgram.c -o MyProgram.exe -O3 -lm -lgsl -lgslcblas

Это приводит к длинной серии сообщений об ошибках вида:

undefined reference to '_imp____infinity'

а также

undefined reference to '_impure_ptr'

из различных GSL-функций. То есть:

/gsl-1.9/specfunc/trig.c:335: undefined reference to '_imp____infinity'

что, похоже, связано с функцией OVERFLOW_ERROR в GSL.

Я скомпилировал GSL из исходников с помощью MSYS (и префиксом configure указал путь к MinGW), но мне кажется, что дело не в привязке к GSL-библиотекам - т.е. функции вроде бы расположены правильно.

Для справки, я могу удалить части программы, основанные на CBLAS (что делает программу несколько бесполезной), и успешно скомпилировать программу, используя:

gcc MyProgram.c -o MyProgram.exe -O3 -lm

где я разместил соответствующие каталоги в PATH.

Я очень озадачен этой неожиданной ошибкой, так как кажется, что ссылка на GSL искажает ссылки на фундаментальные C-библиотеки? Кроме того, программа отлично компилируется в Ubuntu 15.04 (с GSL-флагами).


person Hmmmmm    schedule 08.07.2015    source источник
comment
Я не понимаю, как вы получаете ссылки на __infinity или _impure_ptr в любую сборку MinGW; возможно ли, что у вас есть загрязнение пула заголовков файлами заголовков Linux (или аналогичными)? Из проверки MinGW <math.h> я вижу, что MSVCRT.DLL эквивалентом infinity является _INF; MSDN не документирует impure_ptr, и я не знаю эквивалента MSVCRT.DLL.   -  person Keith Marshall    schedule 08.07.2015
comment
Спасибо за Ваш интерес. Перетасовка флагов компилятора не имеет никакого эффекта (как указал @KeithMarshall). Я еще раз взгляну на свою настройку MinGW, чтобы правильно ответить на второй вопрос и вернуться к вам, но, насколько я помню, большая часть этого в значительной степени просто «из коробки».   -  person Hmmmmm    schedule 08.07.2015


Ответы (1)


Вы определенно должны не использовать ссылки либо на __infinity (что будет преобразовано в ссылку импорта DLL _imp____infinity), либо на _impure_ptr в clean MinGW сборка GSL. Для справки, я только что скачал gsl-latest.tar.gz, распаковал его и сделал (используя Linux-компилятор gcc-4.8.2 mingw32-cross-compiler):

$ mkdir gsl-1.16/build
$ cd gsl-1.16/build
$ ../configure --build=x86_64-linux-gnu --host=mingw32 --prefix=/mingw
...
$ make
$ make prefix=`pwd`/staged install

Это создает следующий контент в staged/lib:

$ ls -R staged/lib
staged/lib:
libgsl.a      libgslcblas.a  libgslcblas.dll.a  libgslcblas.la
libgsl.dll.a  libgsl.la      pkgconfig

staged/lib/pkgconfig:
gsl.pc

и последующий запуск nm на сгенерированных библиотеках подтверждает отсутствие таких ссылок:

$ nm -A staged/lib/*.a | grep infinity
$ nm -A staged/lib/*.a | grep impure_ptr

Я также выполнил STFW для undefined reference to _impure_ptr, но не смог найти ссылку на MSDN; наиболее полезные обращения были к потоку cygwin ML, предполагая, что такие ссылки генерируются, когда пользователь неправильно добавляет путь заголовка cygwin к пути поиска -I компилятора MinGW во время сборки ... т.е. преднамеренное загрязнение пула заголовков.

person Keith Marshall    schedule 08.07.2015
comment
Полагаю, вы абсолютно правы. Я переустановил новейшую версию GSL, используя предложенные вами команды, которые, похоже, решили проблему. Я все еще несколько озадачен тем, как мне удалось ввести Linux-подобные заголовки в пул заголовков, но, похоже, ваш диагноз точен. Большое спасибо за ваши идеи! - person Hmmmmm; 09.07.2015