【发布时间】:2016-12-14 01:19:19
【问题描述】:
使用 LapackE 和 MPI 库用 C++ 编写的代码在我使用 GNU C++ 4.9.2 的 Windows 上编译和运行良好。
将该代码迁移到 Linux (CentOS) 服务器编译失败! Linux 机器上的 GNU C++ 是 4.4.7。在这两种情况下,我都使用了相同的 LapackE 头文件。 MPI 在 Linux 机器上运行良好。
在检查两台机器上的预处理器输出文件后,我可以将错误消息与以下情况联系起来:原始代码中的 complex 声明被 _Complex 替换。以下是在 Linux 上编译时出现问题的复杂动态数组 HAMILTONIAN 的声明示例:
来源: lapack_complex_double* 汉密尔顿式;
在 WINDOWS 预处理中。文件(效果很好): _lapack_complex_double* 汉密尔顿式;
在 LINUX PrePROC 中。文件(编译失败): 双 _Complex* 汉密尔顿式;
这可能是与 GCC 的不同版本有关的问题吗?
我尝试过#define _Complex complex,但最终没有用。
一些报告的 C99 _Complex 和 C++ complex 的互操作性问题:possible similar problem。
请帮忙。谢谢!
【问题讨论】:
-
显而易见的答案是,
/home中包含的头文件之一使用了<complex>和"minMathsForEPM.h"中的某些内容,但没有明确地#include他们自己。因此,您需要自己做。 -
@ Sam Varshavchik :棘手的事情在最后一段,如果在“工作代码”(第二个代码)中添加程序,那么它不起作用并且所有错误都是相关的复杂数量的声明。在 Windows 上编译时不会发生这种情况。
-
你还没有解释“问题”是什么。从总体上看,重新编码包含文件是一件小事,可以在几秒钟内发送出去。 “问题”似乎已经解决:重新排序包含文件。
-
@Sam Varshavchik:真的!我在最后一段中添加了另一个解释。这就是问题的本质。请帮忙。谢谢!
-
Boki,如果你
g++ -E mysourcefile.cpp(假设 g++ 编译器因为 centos)编译器将吐出预处理器的结果而不是可执行文件,结合常规构建时得到的编译器错误应该可以帮助您深入了解真正出了什么问题。为获得最佳结果,请使用与常规构建相同的编译器标志。
标签: c++ linux windows lapack complextype