在 MS VC 2013 Express 中将 C++ dll 从 32 位转换为 64 位

Question

My code can be compiled in both of 32 and 64bit configuration but only the first one works well. I opened the libraries with depends.exe and in case of 64bit I see two error messages:

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module. Error: Modules with different CPU types were found.

In the depends.exe's module list I see the CPU type of my dll is x64 but everything else is x86 (everything else supposed to be dynamically linked). How can I tell to the VC to use 64bit libraries in case of dynamic linking?

There is no warning or error message during the compiling and linking.

Considering the configuration I configured my solution according to MS suggestions and I think there is nothing wrong with that. I can only think for missing macros or wrong lib dependencies or maybe VC options.

EDIT: This is very close to my problem.

EDIT2: In case of the lib I also get error message: Error: At least one file was not a 32-bit or 64-bit Windows module. And No DOS or PE signature found. This file is not a valid 32-bit or 64-bit Win module.

Answer 1

This sort of message from Dependency Viewer is often a red herring, a false positive. If you use the 32 bit version of Dependency Walker with a 64 bit module, it can sometimes think, mistakenly, that your DLL links to 32 bit modules.

You can try instead to use the 64 bit version of Dependency Walker which should work better. However, Dependency Walker is doing a static analysis that does not always yield the same results as the true module loader. If you want to know whether your module can load, you need to get the loader to load it in a running program. For instance by creating a program that links to the DLL.

The simplest way to do that is to create a simple program that calls LoadLibrary to load the library. See if that succeeds or not. If not then you likely have problems with dependencies. They are best debugged using Dependency Walker's profile mode. That debugs the load process dynamically rather than the error-prone static analysis that you have been using.

Of course, it is certainly possible that your DLL will fail to load because the loader comes up with 32 bit DLLs when resolving dependencies. If that is the case then profile mode of Dependency Viewer will reveal the problem and then you can tackle it.

Regarding your question edits, a .lib file is not a PE module. You cannot pass a .lib file to LoadLibrary , or inspect it with Dependency Walker. Perhaps some of the confusion arises because the term library is overloaded. A .lib file is a library, either an import library or a static library. And a DLL is a library, a dynamic link library. In what I wrote above, I used library to refer to DLLs.