2014-02-08 153 views
-1

我得到了一个使用在Windows 8上编译的.dll的程序。当我将程序及其.dll移动到Windows 7时,程序崩溃。这一定是因为DLL编译配置我猜。在Windows 8中编译的DLL在Windows 7中不起作用

下面是.dll

#pragma once 

#ifdef __cplusplus 
extern "C" { 
#endif 

    void myFunc(void); 

#ifdef __cplusplus 
} 
#endif 

的头文件我试过的Dependency Walker,但不明白它的一部分。在Windows 8中,dll有一些缺失的依赖关系,但运行良好。在Windows 7中,该dll缺少的依赖是不同

该程序正在使用TDM MinGW的(它有),而DLL是使用Visual Studio 2013

+0

使用编译'-static -static-libgcc的-static-的libstdC++' – Brandon

+0

@CantChooseUsernames使错误行304:问题编译:mingw32的-G ++:错误:无法识别的选项 '-static-的libstdC++' –

+0

你能紧靠更精确“崩溃”的性质?例如,报告哪些错误消息?无法加载或链接库时是否真的崩溃或中止? – Clifford

回答

1

难怪编译编译。 C++语言的变化往往会迫使ABI的差异(库不再兼容)。操作系统也有些不同...

+0

感谢您的回复。所以我该怎么做?任何建议? –

1

C++用于支持类成员资格和函数重载的名称修改过程因编译器而异。从不保证(并且事实上不太可能)在一个编译器中编写的DLL中的C++符号将匹配在不同编译器中生成的符号。

查看this on name mangling了解详情。最终,无论崩溃的实际原因如何,为DLL和应用程序代码使用不同的编译器可能都是不安全的。

您需要在整个过程中使用相同的编译器,或者使用C链接提供DLL API。

+0

在这种情况下,我不能使用相同的编译器。将尝试使用C链接的DLL API。谢谢 –

+0

@ mnaim86:我的错误,你的头文件显示你已经在使用C链接了(这就是'extern“C”'的用途)。 – Clifford

相关问题