Код C++/LapackE компилируется нормально в Windows, но идентичный код не компилируется в Linux

Код, написанный на C++ с библиотеками LapackE и MPI, отлично компилируется и работает в Windows, где я использую GNU C++ 4.9.2.

При переносе этого кода на сервер Linux (CentOS) не удается скомпилировать! GNU C++ на Linux-машине — 4.4.7. В обоих случаях я использовал идентичные заголовочные файлы LapackE. MPI хорошо работает на машине с Linux.

Изучив выходные файлы препроцессора на обеих машинах, я могу связать сообщения об ошибках со следующими ситуациями, когда объявления complex в исходном коде были заменены на _Complex. Вот пример объявления сложного динамического массива HAMILTONIAN, который имеет проблемы при компиляции в Linux:

В ИСТОЧНИКЕ: lapack_complex_double* HAMILTONIAN;

В WINDOWS PREPROC. ФАЙЛ (работает хорошо): _lapack_complex_double* HAMILTONIAN;

В ПРЕДПРОЦЕССЕ LINUX. ФАЙЛ (не компилируется): double _Complex* HAMILTONIAN;

Может ли это быть связано с разными версиями GCC?

Я пробовал #define _Complex complex, но в итоге это не помогло.

Некоторые сообщали о проблеме взаимодействия C99 _Complex и комплекса C++: возможная аналогичная проблема< /а>.

Пожалуйста помоги. Спасибо!


windows c++ linux complextype lapack
person Boki    schedule 14.12.2016    source источник
comment
Очевидный ответ заключается в том, что один из тех файлов заголовков, которые включены из /home, используют что-то из <complex> и "minMathsForEPM.h", но не могут явно #include их сами. Таким образом, вы обязаны сделать это самостоятельно.   -  person Sam Varshavchik    schedule 14.12.2016
comment
@ Sam Varshavchik : в последнем абзаце хитрость, если в рабочий код (второй код) добавить свою программу, то она не работает и все ошибки связаны с декларациями комплексных величин. Этого не происходит, когда вы компилируете его в Windows.   -  person Boki    schedule 14.12.2016
comment
Вы так и не объяснили, в чем проблема. По большому счету, переупорядочение включаемых файлов — тривиальное дело, с которым можно справиться за несколько секунд. Кажется, проблема уже решена: переупорядочить включаемые файлы.   -  person Sam Varshavchik    schedule 14.12.2016
comment
@ Сэм Варшавчик: правда! Я добавил еще одно объяснение в последний абзац. В этом суть проблемы. Пожалуйста помоги. Спасибо!   -  person Boki    schedule 14.12.2016
comment
Я посмотрю, чтобы добавить больше объяснений в ближайшее время. Спасибо @ Сэм Варшавчик.   -  person Boki    schedule 14.12.2016
comment
Повторяю, вы так и не объяснили, в чем проблема. Вы обнаружили ошибку компиляции, которую устранили путем изменения порядка включаемых файлов. Проблема решена. Следующий вопрос.   -  person Sam Varshavchik    schedule 14.12.2016
comment
Боки, если вы g++ -E mysourcefile.cpp (предполагая компилятор g++ из-за Centos), компилятор выдаст результаты препроцессора вместо исполняемого файла, который в сочетании с ошибкой компилятора, которую вы получаете при обычной сборке, должен помочь вам получить некоторое представление о том, что действительно произошло неправильный. Для достижения наилучших результатов используйте те же флаги компилятора, что и при обычной сборке.   -  person user4581301    schedule 14.12.2016
comment
@user4581301: спасибо за совет, попробую. В любом случае, сегодня я постараюсь переформулировать вопрос.   -  person Boki    schedule 14.12.2016
comment
@ user4581301, вопрос теперь переформулирован и лучше отражает проблему. Спасибо.   -  person Boki    schedule 14.12.2016
comment
@SamVarshavchik: вопрос теперь переформулирован и лучше отражает проблему. Спасибо.   -  person Boki    schedule 14.12.2016
comment
@VladimirF: старый удален. Переформулированный вопрос сильно отличается от исходного. Спасибо.   -  person Boki    schedule 14.12.2016
comment
Хорошо, но имейте в виду, что с несколькими отрицательными или удаленными вопросами вы серьезно рискуете получить бан. Вот почему я рекомендую отредактировать один вопрос до хорошей формы, прежде чем открывать другие. Прочтите stackoverflow.com/help/question-bans.   -  person Vladimir F    schedule 14.12.2016
comment
@VladimirF: спасибо   -  person Boki    schedule 14.12.2016
comment
@ user4581301: Спасибо за приведенный выше совет. Это дает несколько лучшее представление: например, ошибка в строке 27, где находится функция std::complex‹double› Funct_SPINORBIT(...), в файле препроцессора выглядит как std::_Complex‹double› Funct_SPINORBIT(...) ). Может ли это быть источником ошибки со сложными значениями?   -  person Boki    schedule 14.12.2016

Ответы (2)


arrow_upward
1
arrow_downward

он компилируется нормально, даже если я удалю "extern "C" и просто оставлю #include "Headers_LAPACKE/..." в блоке №1 кода.

Сделай это. Заголовки LAPACK содержат #if __cplusplus проверки внутри себя, они разработаны таким образом, что пользовательский код не нуждается и не должен окружать их extern "C".

person Ben Voigt    schedule 14.12.2016
comment
@ Бен Фойгт: Спасибо за отзыв, Бен. Если я удаляю extern C, я получаю больше ошибок. Дополнительные относятся к следующему типу: 1) ошибка: предыдущее объявление 'float _complex_ lapack_make_complex_float(float, float)' со связью 'C++'. 2) ошибка: конфликтует с новым объявлением со связью 'C' Это связано со следующей строкой в ​​заголовке LapackE: lapack_complex_float lapack_make_complex_float( float re, float im ); - person Boki; 15.12.2016
comment
На этом сайте gcc.gnu.org/ml/libstdc++/2007- 02/msg00168.html сказано, что в настоящее время C++ не будет анализировать синтаксис для сложных типов C99, и я знаю о известных предложениях сделать это... Но компиляция работает в Windows. - person Boki; 15.12.2016
comment
@ Ben Voigt: чтобы добавить к моему комментарию выше, все дополнительные ошибки связаны с файлами заголовков LapackE. - person Boki; 15.12.2016
comment
Может ли это быть версия GCC, которую я использую на компьютере с Windows (4.9.4), по сравнению с версией на компьютере с Linux (4.4.7)? - person Boki; 15.12.2016
comment
Это та же версия заголовков библиотеки? - person Ben Voigt; 15.12.2016
comment
@ Ben Voigt: Да, это та же версия заголовочных файлов. - person Boki; 15.12.2016

arrow_upward
1
arrow_downward

Во-первых, установите для компилятора GCC версию 4.8 или выше: в моем случае нам пришлось оставить старый GCC 4.4.7 и одновременно установить GCC 4.9.2. Чтобы иметь возможность использовать более новую версию в компиляции MPI, нужно добавить ее в начало PATH. Для этого см. ответ на Как изменить компилятор GCC по умолчанию для использования с MPI в Linux CentOS

Во-вторых, при компиляции с помощью LapackE (оболочка Lapack для C) необходимо использовать следующие опции препроцессора (-D):

-D LAPACK_COMPLEX_STRUCTURE -D HAVE_LAPACK_CONFIG_H -D ADD_

Пример:

bash-4.1$ mpiCC main.cpp -L/home/USER1/lapack-3.6.1 -llapacke -llapack -lblas -lm -Wall -D LAPACK_COMPLEX_STRUCTURE -D HAVE_LAPACK_CONFIG_H -D ADD_

Убедись, что:

bash-4.1$ gcc --версия

дает 4,8 или выше. В моем случае это было: gcc (GCC) 4.9.3

person Boki    schedule 21.12.2016