Сборка BLAS под VS
vitaly333
Решил тут собрать BLAS под 2005 студией. Ничего не выходит. Скачал
cblas c netlib. Создал проект библиотеки в студии. Собрал её.
Библиотека собралась без проблем. Далее создал другой проект, который
использует эту библиотеку. Подключил только что собранную библиотеку к
проекту. Попробовал вызвать dgemm для проверки но вылетает ошибка...
Не знаю что делать.. Вам не приходилось собирать BLAS под студией?
На всякий случай вот ссылка на проекты
http://rapidshare.de/files/48317113/BLAS_SOLUTION.rar.html
Evgenii Rudnyi
> cblas c netlib. Создал проект библиотеки в студии. Собрал её.
> Библиотека собралась без проблем. Далее создал другой проект, который
> использует эту библиотеку. Подключил только что собранную библиотеку к
> проекту. Попробовал вызвать dgemm для проверки но вылетает ошибка...
> Не знаю что делать.. Вам не приходилось собирать BLAS под студией?
Да, я компилировал и BLAS, и LAPACK в VS. Только я работаю с командной
строки, GUI я не знаю. Правда я использовал Intel Fortran для компиляции
Фортрана.
А какая ошибка получается? При линковании не находится dgemm?
Если я правильно помню, cblas - это только С-интерфейс к BLAS. Самих
BLAS функций там нет. Наверное это тогда было бы объяснением.
На Netlib есть BLAS на Фортране, но его производительность не самая
лучшая. Это просто реализация как точка отсчета. Из бесплатных
оптимизированных BLAS есть ATLAS. Taucs содержит ATLAS, скомпилированный
с VS, правда только с -MT. Если -MT устраивает, то можно взять оттуда.
Другая бесплатная возможность это AMD ACML. Там надо зарегистрироваться,
чтобы его получить, но сам продукт бесплатный.
GOTO BLAS для исследований бесплатный, но там нужен Фортран для компиляции.
vitaly333
> А какая ошибка получается? При линковании не находится dgemm?
Да. Вот:
error LNK2001: unresolved external symbol _F77_dgemm
blas_library.lib
> Если я правильно помню, cblas - это только С-интерфейс к BLAS. Самих
> BLAS функций там нет. Наверное это тогда было бы объяснением.
Т.е. я должен сначала собрать Blas фортраном а потом прилинковать к C-
интерфейсу?
Не могли бы вы написать как это сделать?
> На Netlib есть BLAS на Фортране, но его производительность не самая
> лучшая. Это просто реализация как точка отсчета. Из бесплатных
> оптимизированных BLAS есть ATLAS. Taucs содержит ATLAS, скомпилированный
> с VS, правда только с -MT. Если -MT устраивает, то можно взять оттуда.
>
> Другая бесплатная возможность это AMD ACML. Там надо зарегистрироваться,
> чтобы его получить, но сам продукт бесплатный.
>
> GOTO BLAS для исследований бесплатный, но там нужен Фортран для компиляции.
Было бы неплохо сравнить разные реализации BLAS-а. Я сейчас занимаюсь
как раз сравнением различных алгоритмов умножения матриц.
Evgenii Rudnyi
> Да. Вот:
> error LNK2001: unresolved external symbol _F77_dgemm
> blas_library.lib
Это означает, что при линковании не находится эта подпрограмма. Правда
имя выглядит странно, в исходном BLAS такого нет. Здесь для проверки
полезен nm (входит в состав Cygwin, я не знаю как называется эквивалент
в VS). Например
$ nm libf77blas.lib | grep dgemm
ATL_F77wrap_dgemm.obj:
U _ATL_dgemm
00000000 T _atl_f77wrap_dgemm__
dgemm.obj:
U _atl_f77wrap_dgemm__
00000010 T _dgemm_
показывает, что здесь есть подпрограмма dgemm_ (код T) и есть
подпрограммы, которые используются _ATL_dgemm (код U), но которых как
таковых нет. Они должны быть найдены в других библиотеках.
Быстрый способ понять, что происходит с _F77_dgemm в CBLAS, это
$ grep F77_dgemm *.c *.h
>> Если я правильно помню, cblas - это только С-интерфейс к BLAS. Самих
>> BLAS функций там нет. Наверное это тогда было бы объяснением.
>
> Т.е. я должен сначала собрать Blas фортраном а потом прилинковать к C-
> интерфейсу?
> Не могли бы вы написать как это сделать?
Какой Фортран вы используете вместе с VS? Intel?
>> На Netlib есть BLAS на Фортране, но его производительность не самая
>> лучшая. Это просто реализация как точка отсчета. Из бесплатных
>> оптимизированных BLAS есть ATLAS. Taucs содержит ATLAS, скомпилированный
>> с VS, правда только с -MT. Если -MT устраивает, то можно взять оттуда.
>>
>> Другая бесплатная возможность это AMD ACML. Там надо зарегистрироваться,
>> чтобы его получить, но сам продукт бесплатный.
>>
>> GOTO BLAS для исследований бесплатный, но там нужен Фортран для компиляции.
>
> Было бы неплохо сравнить разные реализации BLAS-а. Я сейчас занимаюсь
> как раз сравнением различных алгоритмов умножения матриц.
Некоторый текст, который вам наверное подойдет, это
http://matrixprogramming.com/MatrixMultiply/
Здесь правда все сделано с gcc из под Cygwin. Это проще, поскольку можно
использовать makefiles практически без изменения.
vitaly333
> Это означает, что при линковании не находится эта подпрограмма. Правда
> имя выглядит странно, в исходном BLAS такого нет. Здесь для проверки
> полезен nm (входит в состав Cygwin, я не знаю как называется эквивалент
> в VS). Например
>
> $ nm libf77blas.lib | grep dgemm
> ATL_F77wrap_dgemm.obj:
> U _ATL_dgemm
> 00000000 T _atl_f77wrap_dgemm__
> dgemm.obj:
> U _atl_f77wrap_dgemm__
> 00000010 T _dgemm_
>
> показывает, что здесь есть подпрограмма dgemm_ (код T) и есть
> подпрограммы, которые используются _ATL_dgemm (код U), но которых как
> таковых нет. Они должны быть найдены в других библиотеках.
>
> Быстрый способ понять, что происходит с _F77_dgemm в CBLAS, это
>
> $ grep F77_dgemm *.c *.h
Вообщем решил я собрать всё это дело под MinGW для проверки.
1) Установил MinGW c MYSYS и набор самых последних GNU компиляторов v
4.4.0, включая GCC и GFORTRAN.
2) Скачал с Нетлиба фортрановский blas и С-интерфейс к нему.
3) Собрал blas GFortran-ом. В итоге получилaсь libBLAS.a (пришлось в
makefile заменить F77 на GFORTRAN)
4) Собрал C-интерфейс, используя GCC. В итоге получилась libCBLAS.a
5) Создал С++ - проект под MinGW. К нему прилинковал обе библиотеки.
Вот код С++:
===========================================================================================
extern "C"{
#include "cblas.h"
#include "cblas_f77.h"
}
int main() {
int N = 1024;
double *A = new double[N];
double *B = new double[N];
double *C = new double[N];
int k = 0;
for (int i=0;i<N*N;i++){
A[i] = k;
B[i] = k;
C[i] = 0.0;
}
cblas_dgemm(CblasRowMajor,CblasNoTrans,CblasNoTrans,N, N, N, 1.0, A,
N, B, N, 0.0, C, N);
return 0;
}
==========================================================================================
При попытке скомпилировать всё это вылетает почти таже ошибка:
g++ -I../include -I../lib -O0 -g3 -Wall -c -fmessage-length=0 -osrc
\Main.o ..\src\Main.cpp
g++ -L../lib -oDGEMM.exe src\Main.o -lBlas -lCblas
../lib/libCblas.a(cblas_dgemm.o):cblas_dgemm.c:(.text+0x12d):
undefined reference to `dgemm_'
Далее я решил их проверить как вы писали:
1) Сначала я проверил сам Blas на dgemm:
$ nm libBLAS.a | grep dgemm
dgemm.o:
00000000 T _dgemm_
Он там действительно есть, но называется почему-то _dgemm_?
2) Теперь C-интерфейс:
$ nm libCBLAS.a | grep dgemm
cblas_dgemm.o:
00000000 T _cblas_dgemm
U _dgemm_
Т.е. в библиотеке libCBLAS.a есть функция _cblas_dgemm, которая внутри
себя вызывает _dgemm_ так ведь? Всё вроде правильно.
Только опять, откуда опять эти черточки?
Далее решил потправить хидеры и исходник с учётом черточек (подумал,
может быть в них дело?):
1) В cblas_f77.h:
Вместо:
#define F77_dgemm dgemm_
Поставил:
#define F77_dgemm _dgemm_
2) В cblas.h и Main.cpp:
Заменил: cblas_dgemm на _cblas_dgemm
Ошибка осталась прежней.
> Какой Фортран вы используете вместе с VS? Intel?
Собираюсь использовать Intel, но пока ещё не пробовал, потому что
думал что cblas - это полная С библиотека, а не интерфейс к фортрану.
Думаю, что если откомпилировать Blas Интелом, а потом прилинковать к
моему проекту на VS, то тоже ничего не изменится.
vitaly333
проектом. Ошибка осталась.
Evgenii Rudnyi
>
> $ nm libBLAS.a | grep dgemm
> dgemm.o:
> 00000000 T _dgemm_
> Он там действительно есть, но называется почему-то _dgemm_?
>
> 2) Теперь C-интерфейс:
> $ nm libCBLAS.a | grep dgemm
> cblas_dgemm.o:
> 00000000 T _cblas_dgemm
> U _dgemm_
>
> Т.е. в библиотеке libCBLAS.a есть функция _cblas_dgemm, которая внутри
> себя вызывает _dgemm_ так ведь? Всё вроде правильно.
> Только опять, откуда опять эти черточки?
Это идет из истории. Черточку спереди ставят все компиляторы, поскольку
у них есть свои специальные символы и это делается, чтобы
пользовательские символы не совпали с ними.
Черточку сзади ставили компиляторы с Фортрана. Наверное для надежности.
Скажем g77 делает это и сейчас по умолчанию. Однако это может быть и не
так и надо это проверять.
Линкер пишет
undefined reference to `dgemm_'
однако он скорее всего не пишет про черточку спереди, поскольку она все
равно специальная. Итак, nm показывает, что все правильно. libCBLAS.a
вызывает _dgemm_, и он есть в libBLAS.a. Проблема здесь в том, что в gcc
есть правило, что библиотека проверяется только один раз. В вашем случае
$ g++ -L../lib -oDGEMM.exe src\Main.o -lBlas -lCblas
Blas стоит перед Cblas. То есть в момент проверки Blas никто не
спрашивает про dgemm_ и второй раз она уже проверяется. Надо поменять
последовательность
$ g++ -L../lib -oDGEMM.exe src\Main.o -lCblas -lBlas
Так должно сработать.
> Далее решил потправить хидеры и исходник с учётом черточек (подумал,
> может быть в них дело?):
>
> 1) В cblas_f77.h:
> Вместо:
> #define F77_dgemm dgemm_
> Поставил:
> #define F77_dgemm _dgemm_
>
> 2) В cblas.h и Main.cpp:
> Заменил: cblas_dgemm на _cblas_dgemm
>
> Ошибка осталась прежней.
Теперь уже по идее линкер должен написать, что он не может найти _dgemm_.
>> Какой Фортран вы используете вместе с VS? Intel?
>
> Собираюсь использовать Intel, но пока ещё не пробовал, потому что
> думал что cblas - это полная С библиотека, а не интерфейс к фортрану.
> Думаю, что если откомпилировать Blas Интелом, а потом прилинковать к
> моему проекту на VS, то тоже ничего не изменится.
Все будет, но там уже по умолчанию черточка сзади не добавляется и более
того символы конвертируются в верхний регистр. В этом случае надо будет
сделать что-то следующее
http://matrixprogramming.com/LAPACK/dgesv.cpp
Вот небольшая заметка про вызов Фортрана
vitaly333
> Надо поменять последовательность
Поменял, но теперь вываливаются др. ошибки:
to `_gfortran_st_write'
../lib/libBlas.a(xerbla.o):xerbla.f:(.text+0x67): undefined reference
to `_gfortran_transfer_character'
../lib/libBlas.a(xerbla.o):xerbla.f:(.text+0x7e): undefined reference
to `_gfortran_transfer_integer'
../lib/libBlas.a(xerbla.o):xerbla.f:(.text+0x86): undefined reference
to `_gfortran_st_write_done'
../lib/libBlas.a(xerbla.o):xerbla.f:(.text+0x92): undefined reference
to `_gfortran_stop_numeric'
Evgenii Rudnyi
Это уже g++ по умолчанию не вызывает библиотеки Фортрана. С другой
стороны gfortran по умолчанию не будет вызывать библиотеки C++. Надо
добавить -lgfortran или что-то типа такого, я не знаю какие библиотеки
использует gfortran. Это можно увидеть с опцией -v. Скажем
$ g++ -v t.cpp
$ gfortran -v t.f
В целом вы уже близки к успеху. Вызывать Фортран из С++ в конечном итоге
требует усилий, но не так уж и сложно. Здесь надо
1) понять что делает компилятор Фортрана с именами
2) подключить бибилиотеки Фортрана вручную
В общем наверное и все.
vitaly333
> Это уже g++ по умолчанию не вызывает библиотеки Фортрана. С другой
> стороны gfortran по умолчанию не будет вызывать библиотеки C++. Надо
> добавить -lgfortran или что-то типа такого, я не знаю какие библиотеки
> использует gfortran. Это можно увидеть с опцией -v. Скажем
библиотеки gfortranbegin и gfortran. Прилинковал их и всё заработало.
Спасибо вам за подсказки.
Теперь мне потребовалось собрать Atlas под Windows, используя
компиляторы от Интел. На сколько я знаю там не всё так тривиально как
с Нетлибовским бласом, т.е. нельзя напрямую скопировать исходники в
студию и создать там библиотеку. Нужно собирать через конфигуратор,
т.к. при сборке Atlas запускает множество тестов, чтобы получить
наиболее высокопроизводительную библиотеку. Как здесь быть?
Evgenii Rudnyi
> компиляторы от Интел. На сколько я знаю там не всё так тривиально как
> с Нетлибовским бласом, т.е. нельзя напрямую скопировать исходники в
> студию и создать там библиотеку. Нужно собирать через конфигуратор,
> т.к. при сборке Atlas запускает множество тестов, чтобы получить
> наиболее высокопроизводительную библиотеку. Как здесь быть?
Я думаю, что использовать конфигуратор. Другого выхода я не вижу. Там в
принципе можно переопределить компиляторы, правда по-моему в
документации это не рекомендуется. Здесь лучше спросить на форуме ATLAS.
С другой стороны если использовать компиляторы Интел, то почему ж не
использовать Intel MKL? Это было бы проще. MKL не бесплатная, но вполне
возможно что по затратам это будет дешевле, чем компилировать ATLAS.
Также есть AMD ACML, она уже бесплатная.
Еще одно решение - Goto BLAS. Как говорят, его проще компилировать.
vitaly333
Так вот у меня и стоит задача сравнить производительность всех этих
библиотек а так же свои варианты. Для сравнений нужно чтобы все
библиотеки были собраны одним и тем же компилятором. Лучшие
компиляторы на сегодня - это компиляторы от Интел.
Поэтому Atlas нужно всё таки собирать Intel -ом.
vitaly333
получается.
Делаю как написано в мане:
1. Распаковываю архив в /home/atlas3.9.14/ATLAS
2. Захожу в эту папку и создаю там build-директорию Build
3. Захожу в build и запускаю конфигуратор: ../configure -b 32 --
prefix=/home/atlas3.9.14/ATLAS
Через некоторое время появляется ошибка:
Bad OS value=0, ierr=1, ln2=''
OS configured as UNKNOWN <0>
Assertion failed: iret, file C:/msys/1.0/home/atlas3.9.14/ATLAS/CONFIG/
src/config.c, line 334
и потом ещё:
This application has requested the Runtime to terminate it in an
unusial way.
Please contact the application's support team for more information.
Указал ОС в ключе:
../configure -O OSWinNT -b 32 --prefix=/home/atlas3.9.14/ATLAS
тоже самое
Evgenii Rudnyi
> получается.
Я последний компилировал ATLAS 3.6 под Cygwin уже несколько лет назад с
gcc 3.3.
На страничке
http://math-atlas.sourceforge.net/errata.html
Windows упоминается, то есть похоже, что это в принципе возможно. Сложно
сказать.
Evgenii Rudnyi
> Попробовал пока собрать Atlas под MinGW GCC - компилятором. Также не
> получается.
Тут в группе math-atl...@lists.sourceforge.net как раз была записка
от разработчика ATLAS на эту тему. Он просил помощи в документации о
компиляции ATLAS на Windows и там образуется рабочая группа на эту тему
с форумом здесь
http://sourceforge.net/projects/math-atlas/forums/forum/1026734
Попробуйте ему написать.
vitaly333
> Попробуйте ему написать.
Спасибо за ссылку. Попробую это сделать. Кстати говоря, попробовал
собрать gotoBlas. Там также возникают ошибки при компиляциии.
Завел дискусию на эту тему на форуме Lapack
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1595&sid=1370dada242d5af7de6a73303d48c636,
но пока ответы, которые там дают ничем не помогают. Также пока не
получается вызвать DGEMM из BLAS напрямую из фортана (минуя C
интерфейс CLAS - c ним в VS возникают проблемы) в Visual Studio
проекте. Саму ф-ю DGEMM линкер находит в подключенной к проекту BLAS
библиотеке, но вываливаются ошибки связанные с конфликтом библиотек
MSVCRT.lib и LIBCMT.lib. Вообщем у меня не получается использовать не
одну из Blas библиотек под VS. Только подключение INTEL MKL к моему VS-
проекту прошло гладко, ну это и понятно почему, с остальными возникают
проблемы либо на стадии сборки либо на стадии линковки/
выполнения.
Evgenii Rudnyi
> собрать gotoBlas. Там также возникают ошибки при компиляциии.
> Завел дискусию на эту тему на форуме Lapack
> http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1595&sid=1370dada242d5af7de6a73303d48c636,
> но пока ответы, которые там дают ничем не помогают. Также пока не
> получается вызвать DGEMM из BLAS напрямую из фортана (минуя C
> интерфейс CLAS - c ним в VS возникают проблемы) в Visual Studio
> проекте. Саму ф-ю DGEMM линкер находит в подключенной к проекту BLAS
> библиотеке, но вываливаются ошибки связанные с конфликтом библиотек
> MSVCRT.lib и LIBCMT.lib.
Это ознает, что у вас есть части скомпилированные с -MT и -MD. Это
нехорошо, лучше всего скомпилировать все с одним ключом.
vitaly333
> Это ознает, что у вас есть части скомпилированные с -MT и -MD. Это
> нехорошо, лучше всего скомпилировать все с одним ключом.
Установил везде -MT, но теперь вылетает уже райнтайм ошибка:
Unhandled exception at 0x00409bcd in MatrixMultiply.exe: 0xC0000005:
Access violation reading location 0x00000000.
Evgenii Rudnyi
>> Это ознает, что у вас есть части скомпилированные с -MT и -MD. Это
>> нехорошо, лучше всего скомпилировать все с одним ключом.
У MS VC есть несколько типов run-time библиотек. Эти ключи выбирают один
из типов. Насколько я помню -MD - это динамические библиотеки, а -MT
статические. Соотвественно в одном приложении их смешение ни к чему
хорошему не приводит.
К слову сказать, здесь
http://matrixprogramming.com/MatrixMultiply/
есть описание использование DGEMM с gcc (reference BLAS и ATLAS). С VC
использование reference BLAS должно быть похоже. А какие проблемы у вас
возникают в этом случае?
Evgenii Rudnyi
Это уже что-то с памятью. Скорее всего вы выходите за границы массива.
Здесь надо вставлять печать и смотреть в каком месте это происходит.
vitaly333
>Здесь надо вставлять печать и смотреть в каком месте это происходит.
из Нетлибовского блас заработало.
Осталось разобратся как правильно собрать Goto и Atlas чтобы их можно
было юзать под VS.
Evgenii Rudnyi
> было юзать под VS.
Я бы посоветовал начать с Goto. Здесь должно быть легче, поскольку в
Atlas это не то, чтобы просто компиляция.
Если будут ошибки при сборке Goto, то напишите какие. Тогда можно будет
подумать в чем причина.
С Atlas лучше обращаться по ссылке, которую я давал. Я могу помочь
только со сборкой Atlas 3.6 под cygwin.
vitaly333
> подумать в чем причина.
Ошибки есть. На форуме Lapack, ссылку на который я уже приводил, есть
даже инструкция по сборке Goto под Windows. Я всё делаю точно как
написано в инструкции. Скачал и установил Cygwin и GNU компиляторы для
него. Прописал нужные пути. Дело, в том что в моей системе, если явно
не указать какой будет использоватся Фортран компилятор, то по
умолчанию будет использован компилятор Intel Fortran(я не знаю почему,
возможно потому что путь к интел фортану в переменной среды PATH
прописан впереди пути к GNU FORTAN). Поэтому я явно указываю сборщику,
чтобы он использовал именно GFORTRAN, поставляемый вместе с Cygwin.
Выполнив из под командной строки Cygwin вот эту команду:
$ make BINARY=32 USE_THREAD=0 CC=GCC-4 FC=gfortran-4
Начинается сборка библиотеки. Сначала всё идет нормально, но как
только сборка доходит до тестов вылетает ошибка:
cblas_strmm PASSED THE TEST OF ERROR-EXITS
******* FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF ACCURATE
*******
EXPECTED RESULT COMPUTED RESULT
1 -0.412587 0.00000
THE ARE THE RESULTS FOR COLUMN 1
******* cblas_strmm FAILED ON CALL NUMBER:
At line 1405 of file с_sblat3.f
Fortran runtime error: Bad unit number in OPEN statement
make[1]:*** [all3] Error 2
make[1]: Leaving directoey '/home/gotoblas/ctest'
make: *** [tests] Error 2
Но тем не менее, сама библиотека libgoto_athlon-r1.06.a создается в /
home/gotoblas. Далее я делаю как написано в той инструкции, запускаю
коммандную строку Visual Studio 2008 prompt. Захожу через неё в /home/
gotoblas/exports и даю команду на генерацию Windows -библиотек, но
скорее всего так как библиотека libgoto_athlon-r1.06.a не была
полностью собрана я получаю:
C:\cygwin\home\GotoBLAS\exports>make dll
cat: ftest.s: No such file or directory
make: *** No rule to make target `../libgoto_athlon-r1.06.a', needed
by `libgoto.dll'. Stop.
Так же пробовал собрать Goto, используя Intel Fortran. Все пути к
библиотекам и бинам ifort прописаны переменных среды. Сначала я
попробовал собрать через коммандную строку Gygwin, выполнив след.
комманду:
$ make BINARY=32 USE_THREAD=0 CC=GCC-4 FC=ifort
link: invalid option -- o
make: ***[getarch] Error1
..................................
..................................
catastrophic error: could not open source file "unistd.h"
compilation aborted for axpy.c <code 4>
make[1]: *** [saxpy.o] Error4
make[1]: Leaving directory '/home/gotoBLAS/interface'
make:*** [Libs] Error 1
Далее я попробовал собрать goto не из под Gygwin command prompt, а из
под windows cmd, используя тот же самый Intel Fortran. Дав комманду:
make BINARY=32 USE_THREAD=0 CC=GCC-4 FC=ifort
Я получяю ошибки на тестах:
make -C test all
make[1]: Entering directory `/home/GotoBLAS/test'
ifort -O2 -c sblat1.f -o sblat1.o
ifort: command line warning #10161: unrecognized source type
'sblat1.o'; object
file assumed
-out:sblat1.exe
-subsystem:console
sblat1.o
../libgoto_athlon-r1.06.a
LINK : fatal error LNK1181: cannot open input file 'sblat1.o'
make[1]: *** [sblat1] Error 157
make[1]: Leaving directory `/home/GotoBLAS/test'
Библиотека libgoto_athlon-r1.06.a также создается в корневой
директории Goto, но видимо опять не полностью.
Попытавшись снова получить Windows-библитеки я получаю ту же ошибку:
make: *** No rule to make target `../libgoto_athlon-r1.06.a', needed
by `libgoto.dll'. Stop.
Evgenii Rudnyi
>> Если будут ошибки при сборке Goto, то напишите какие. Тогда можно будет
>> подумать в чем причина.
>
> Ошибки есть. На форуме Lapack, ссылку на который я уже приводил, есть
> даже инструкция по сборке Goto под Windows. Я всё делаю точно как
> написано в инструкции. Скачал и установил Cygwin и GNU компиляторы для
> него. Прописал нужные пути. Дело, в том что в моей системе, если явно
> не указать какой будет использоватся Фортран компилятор, то по
> умолчанию будет использован компилятор Intel Fortran(я не знаю почему,
> возможно потому что путь к интел фортану в переменной среды PATH
> прописан впереди пути к GNU FORTAN).
Можно попробовать убрать Intel с пути.
> Поэтому я явно указываю сборщику,
> чтобы он использовал именно GFORTRAN, поставляемый вместе с Cygwin.
> Выполнив из под командной строки Cygwin вот эту команду:
> $ make BINARY=32 USE_THREAD=0 CC=GCC-4 FC=gfortran-4
> Начинается сборка библиотеки. Сначала всё идет нормально, но как
> только сборка доходит до тестов вылетает ошибка:
>
> cblas_strmm PASSED THE TEST OF ERROR-EXITS
> ******* FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF ACCURATE
> *******
> EXPECTED RESULT COMPUTED RESULT
> 1 -0.412587 0.00000
> THE ARE THE RESULTS FOR COLUMN 1
> ******* cblas_strmm FAILED ON CALL NUMBER:
> At line 1405 of file с_sblat3.f
> Fortran runtime error: Bad unit number in OPEN statement
> make[1]:*** [all3] Error 2
> make[1]: Leaving directoey '/home/gotoblas/ctest'
> make: *** [tests] Error 2
В целом это нехорошо. А в документации говорится что-нибудь про
компиляторы?
> Но тем не менее, сама библиотека libgoto_athlon-r1.06.a создается в /
> home/gotoblas. Далее я делаю как написано в той инструкции, запускаю
> коммандную строку Visual Studio 2008 prompt. Захожу через неё в /home/
> gotoblas/exports и даю команду на генерацию Windows -библиотек, но
> скорее всего так как библиотека libgoto_athlon-r1.06.a не была
> полностью собрана я получаю:
> C:\cygwin\home\GotoBLAS\exports>make dll
> cat: ftest.s: No such file or directory
> make: *** No rule to make target `../libgoto_athlon-r1.06.a', needed
> by `libgoto.dll'. Stop.
Может быть вы выполняете эту команду не из той директории? Это говорит,
что в данный раздел make зависит от ../libgoto_athlon-r1.06.a, а make не
может найти этот файл. Здесь речь не идет, что в библиотеке чего-то не
хватает, make не может ее найти. Надо посмотреть, что написано в makefile.
> Так же пробовал собрать Goto, используя Intel Fortran. Все пути к
> библиотекам и бинам ifort прописаны переменных среды. Сначала я
> попробовал собрать через коммандную строку Gygwin, выполнив след.
> комманду:
> $ make BINARY=32 USE_THREAD=0 CC=GCC-4 FC=ifort
> link: invalid option -- o
> make: ***[getarch] Error1
> ..................................
> ..................................
> catastrophic error: could not open source file "unistd.h"
> compilation aborted for axpy.c <code 4>
> make[1]: *** [saxpy.o] Error4
> make[1]: Leaving directory '/home/gotoBLAS/interface'
> make:*** [Libs] Error 1
Странно. Здесь почему-то вызывается link в этом случае.
> Далее я попробовал собрать goto не из под Gygwin command prompt, а из
> под windows cmd, используя тот же самый Intel Fortran. Дав комманду:
> make BINARY=32 USE_THREAD=0 CC=GCC-4 FC=ifort
> Я получяю ошибки на тестах:
>
> make -C test all
> make[1]: Entering directory `/home/GotoBLAS/test'
> ifort -O2 -c sblat1.f -o sblat1.o
> ifort: command line warning #10161: unrecognized source type
> 'sblat1.o'; object
> file assumed
> -out:sblat1.exe
> -subsystem:console
> sblat1.o
> ../libgoto_athlon-r1.06.a
> LINK : fatal error LNK1181: cannot open input file 'sblat1.o'
> make[1]: *** [sblat1] Error 157
> make[1]: Leaving directory `/home/GotoBLAS/test'
Здесь похоже, что ifort не понимает -o sblat1.o. Он трактует, что он
должен что-то сделать с файлом sblat1.o и его не находит.
> Библиотека libgoto_athlon-r1.06.a также создается в корневой
> директории Goto, но видимо опять не полностью.
> Попытавшись снова получить Windows-библитеки я получаю ту же ошибку:
> make: *** No rule to make target `../libgoto_athlon-r1.06.a', needed
> by `libgoto.dll'. Stop.
Это довольно типичная ситуация, когда make не срабатывает. Здесь надо
почитать, что написано в makefile. Это не должно быть очень сложно, по
крайней мере это здесь будет гораздо проще, чем разбираться с ATLAS.