dll2lib转换由.def生成的DLL，链接出错解决办法
dll2lib转换由.def生成的DLL，链接出错
用_declspec(dllexport)导出的函数DLL2lib生成的静态库可以正常使用，但是用.def文件导出的DLL函数，DLL2Lib生成的静态库,不能使用呀
链接时报错
UseDLL.obj : error LNK2001: 无法解析的外部符号
请问有谁遇到过吗，肿么解决，谢谢
------解决方案--------------------
摘自:DLL2LIB.HLP
Resolve Symbols
One difficulty for DLL to Lib is to resolve the symbol names exported by the DLL. When the DLL is converted into a static library, the static library will provide a programming interface consisting of symbols exported from the DLL. And when your project calls the functions in the static library, it will require these exported symbols. In ideal case, the symbol name required by the project and those provided by the static library match exactly, then the linker will "link" these two modules correctly. However, in some cases, the compiler and linker will change the symbols you see by decorating them, which will cause a symbol mismatch and result in a link error such as:
Test.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __thiscall CDLL::MyClassFun(void)" (__imp_?MyClassFun@CDLL@@QAEHXZ)
This error means the linker cannot find a matched symbol from the project's objects and libraries. If you cannot determine whether the library containing the symbols has been added into the project settings, then use
Symbol Finder to find the necessary import libraries and add them. Otherwise, it is surely a symbol mismatch. DLL to Lib provide third methods to solve the problem:
If you do have the import library for the DLL, then add it to the "Import Lib Files for the DLL" list, it is the simplest and most effective way to solve the symbol mismatch problem.
If you do not have the import library for the DLL, then DLL to Lib will assume all of the export symbols in the DLL obey __cdecl call convention. However, if your project does not obey the __cdecl call convention when calling the export symbols, then a symbol mismatch will occurs. And you will find some link errors like this:
Test.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __thiscall CDLL::MyClassFun(void)" (__imp_?MyClassFun@CDLL@@QAEHXZ)
Add the symbol name __imp_?MyClassFun@CDLL@@QAEHXZ and into the "Resolve Symbols" list in the Advanced Conversion Options. Then reconvert your DLL and rebuild your project, the error will disappear. This method is post-know, because you cannot solve the problem until you have known the link errors.
If you do not have the import library for the DLL, then DLL to Lib will assume all of the export symbols in the DLL obey __cdecl call convention. However, if your project does not obey the __cdecl call convention when calling the export symbols, then a symbol mismatch will occurs. To solve the problem, you can also force the call in your project obey the __cdecl call convention. for example, if a DLL function in your project is declared as:
int Hello(int i);
then you can force the call to Hello obey the __cdecl call convention by modify the declaration to:
extern "C" int Hello(int i);
用_declspec(dllexport)导出的函数DLL2lib生成的静态库可以正常使用，但是用.def文件导出的DLL函数，DLL2Lib生成的静态库,不能使用呀
链接时报错
UseDLL.obj : error LNK2001: 无法解析的外部符号
请问有谁遇到过吗，肿么解决，谢谢
------解决方案--------------------
摘自:DLL2LIB.HLP
Resolve Symbols
One difficulty for DLL to Lib is to resolve the symbol names exported by the DLL. When the DLL is converted into a static library, the static library will provide a programming interface consisting of symbols exported from the DLL. And when your project calls the functions in the static library, it will require these exported symbols. In ideal case, the symbol name required by the project and those provided by the static library match exactly, then the linker will "link" these two modules correctly. However, in some cases, the compiler and linker will change the symbols you see by decorating them, which will cause a symbol mismatch and result in a link error such as:
Test.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __thiscall CDLL::MyClassFun(void)" (__imp_?MyClassFun@CDLL@@QAEHXZ)
This error means the linker cannot find a matched symbol from the project's objects and libraries. If you cannot determine whether the library containing the symbols has been added into the project settings, then use
Symbol Finder to find the necessary import libraries and add them. Otherwise, it is surely a symbol mismatch. DLL to Lib provide third methods to solve the problem:
If you do have the import library for the DLL, then add it to the "Import Lib Files for the DLL" list, it is the simplest and most effective way to solve the symbol mismatch problem.
If you do not have the import library for the DLL, then DLL to Lib will assume all of the export symbols in the DLL obey __cdecl call convention. However, if your project does not obey the __cdecl call convention when calling the export symbols, then a symbol mismatch will occurs. And you will find some link errors like this:
Test.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __thiscall CDLL::MyClassFun(void)" (__imp_?MyClassFun@CDLL@@QAEHXZ)
Add the symbol name __imp_?MyClassFun@CDLL@@QAEHXZ and into the "Resolve Symbols" list in the Advanced Conversion Options. Then reconvert your DLL and rebuild your project, the error will disappear. This method is post-know, because you cannot solve the problem until you have known the link errors.
If you do not have the import library for the DLL, then DLL to Lib will assume all of the export symbols in the DLL obey __cdecl call convention. However, if your project does not obey the __cdecl call convention when calling the export symbols, then a symbol mismatch will occurs. To solve the problem, you can also force the call in your project obey the __cdecl call convention. for example, if a DLL function in your project is declared as:
int Hello(int i);
then you can force the call to Hello obey the __cdecl call convention by modify the declaration to:
extern "C" int Hello(int i);