I need to use a static library in my Qt5 project. I'm using VC++ 2010 as my compiler and QtCreator as IDE.
If I use the dynamic version (.DLL) everything works fine.
If I try to use the static version (.LIB) it seems like the library is looking for other dependencies that can't be satisfied.
Sadly, using the DLL is not an option for my project.
The point is that if I try to use the static library from VC++ IDE everything works fine.
Please note that I can use other VC++ headers without any problem in my Qt project.
It seems like the compiler can find everything it needs (basically, my source code and all the required headers) while the linker is missing something.
error: LNK2019: unresolved external symbol _imp_SystemTimeToVariantTime#8 referenced in function "bool __cdecl SystemTimeToMinute(struct _SYSTEMTIME *,unsigned long *)" (?SystemTimeToMinute##YA_NPAU_SYSTEMTIME##PAK#Z)
SystemTimeToVariantTime is defined in OleAut32.lib.
Am I wrong expecting the linker to automatically look for needed libraries and headers based on the content of the global variables INCLUDE and LIB?
Solved.
The problem was that I was trying to include external (SDK) libraries using
LIBS += -l OleAut32.lib
While I had to simply use
LIBS += OleAut32.lib
Well, problem solved.
I hope this can help someone in the future!
Related
I am porting a legacy app (originally compiled with VC 6.0) to MSVC 2019. It uses a legacy static library (libtest.lib), compiled with VC 6.0. My problem is that some (but not all) standard libc functions in libtest.lib are not being resolved by MSVC 2019.
For example, libtest.lib uses vsprintf(). On compilation MSVC 2019 reports "unresolved external symbol _vsprintf referenced in ...". Other libc functions (e.g. strlen) are resolved just fine.
I've tried mucking with a gazillion build settings with no joy.
Why is this happening and how can I fix it?
My research so far...
I did a lot of digging in the VC60 headers and found that vsprintf is defined in studio.h as
_CRTIMP int __cdecl vsprintf(char *,const char *, va_list);
while strlen in defined in string.h
as
size_t __cdecl strlen(const char *);
I'm not sure of the implications but I'm guessing that strlen is just a plain-vanilla static function while vsprintf is imported from some CRT DLL (which is probably different in MSVC 2019).
I guess I could port libtest.lib to MSVC 2019 too, but I've got close to 100 other static libraries and porting them all would be a major pain in the butt.
Thanks to #dewaffled for this great answer:
Microsoft has a library to adapt CRT functions to the latest versions of MSVC e.g., 2019
Simply add the following line to your main program:
#pragma comment(lib, "legacy_stdio_definitions.lib")
Alternatively, I think you can add the library to:
Project Properties -> Linker -> Input -> Additional Dependencies
I upgraded my Win32 project from VC6 to VC2010, and fixed a lot of codes which only work on VC6, compiling is OK, but when the project began linking, it failed with the following message
LINK : fatal error LNK1104: cannot open file 'mfc42ud.lib'
I tried to find where the MFC42ud is referred, but I cannot, it drives me mad.
Could anyone help me?
updated:
Now I downloaded the MFC42ud.lib, but there is still link error, now it becomes
atlsd.lib(atltypes.obj) : error LNK2005: "public: __thiscall CRect::CRect(void)" (??0CRect##QAE#XZ) already defined in mfc42ud.lib(MFC42uD.DLL)
atlsd.lib(atltypes.obj) : error LNK2005: "public: int __thiscall CRect::Width(void)const " (?Width#CRect##QBEHXZ) already defined in mfc42ud.lib(MFC42uD.DLL)
atlsd.lib(atltypes.obj) : error LNK2005: "public: int __thiscall CRect::Height(void)const " (?Height#CRect##QBEHXZ) already defined in mfc42ud.lib(MFC42uD.DLL)
LINK : fatal error LNK1104: cannot open file 'mfcs42ud.lib'
It seems it is not compatible if I just copy the MFC42ud.lib, so now error is multiple definition
OK, at last I resolved it. It is because there are some libs I need link, and there is some linkage information in these libs.
The reason is the Microsoft VC specified preprocessor #pragma comment(lib, "some.lib")
Actually it is really a bad solution, especially to link system provided libs, like mfc libs. Even you upgraded the project, it still wants to link the old mfc libs.
The solution is to ignore the old mfc libs.
It is Unicode Debug version of the MFC DLL for Visual Studio 6, part of optional parts during Visual Studio 6 installation.
Install it from the VS6 installation CD.
Reference: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/46a26f16-a407-4628-962b-2a6899391293/
p.s. it's Google's first result, by the way.
In my case, my project was linking against another library, and that library had been built with
#pragma comment(lib, "mfc42.lib")
inside it.
Linking that library into my project instructed my project to link against mfc42.lib, even though I never had any such setting.
Tracking down and removing the offending library was not easy.
I am working on an (unmanaged) x64 Win32 C++ application in Visual Studio 2010 Pro, and keep getting a strange linking error.
This application makes use of the LoadImage() Windows API function through including windows.h. While the application compiles fine in the Release configuration (and LoadImage() does its job), I cannot get the executable linked in the Debug configuration. I keep getting this error:
Redacted.obj : error LNK2019: unresolved external symbol __imp_LoadImageW referenced in function "public: int __cdecl Redacted::Redacted::Execute(void)" (?Execute#Redacted#Redacted##QEAAHXZ)
C:\Users\redacted\Documents\Visual Studio 2010\Projects\Redacted\x64\Debug\Redacted.exe : fatal error LNK1120: 1 unresolved externals
If I switch from Unicode to non-multi-byte character set, the error message will change from LoadImageW() to LoadImageA() accordingly, but otherwise persist. As I cannot find any relevant differences in the properties for the Release and Debug configuration, I am at a loss why it will compile in one, but not the other. User32.lib is correctly set as an Additional dependency for the Linker in both configurations, and the /MACHINE:X64 flag is set in both as well.
Since the linker doesn't complain about not finding the User32.lib, I am led to believe that it tries to link a wrong version from the Platform SDK, i.e. the 32-bit one. But how can I find out which exact copy of a LIB file the linker actually tries to use?
Check the linker paths in the global configuration settings. Most probably one of those is wrong.
Beyond that, I believe there's a linker /VERBOSE flag (or something similar) which will display the information you're looking for. It's somewhere in the linker settings for the project you're building.
We have a DLL, built with MS Visual Studio 2010, in release mode. We provide this DLL to different customers, along with a .lib file. The functions in the DLL are exported with:
extern "C" __declspec(dllexport) int analyze(int id);
Our customers have two applications that makes use of this DLL. Both of these applications import the DLL functions using:
extern "C" __declspec(dllimport) int analyze(int id);
One of these applications is built with MS Visual Studio 2010. This application can be built successfully in both debug and release modes.
The other application must unfortunately use MS Visual Studio 2005 as its build environment. In this application, the release build can be built successfully, however, when we try to build in debug mode, we get linker errors:
LNK2019: unresolved external symbol __imp_analyze referenced in function "void __cdecl process(char const *,char const *)" (?process##ABCERFG0#Z)
Can someone help me understand what we are missing here? Are we exporting the functions in a manner that is not portable across compilers? What's the solution?
Regards,
The .obj file format is highly conserved between VS2005 and VS2010. This should not be a problem, especially since it is a simple non-mangled symbol reference. And especially not when it works in the Release configuration but not in Debug. A simple explanation is always better than a convoluted one: your customer simply forgot to add your .lib file to the linker's Additional Dependencies setting.
Beware that the setting change needs to be made for both configurations, use the "Configuration" combo in the upper left corner of the dialog.
You can help your customer fall into the pit of success by using #pragma comment(lib, "mumble.lib") in your .h file.
I'm new to Windows concepts. I'm trying to develop a DLL that also dynamically links against other DLL's. I'm using Visual Studio 2010. At linking time Visual studio tells me it's trying to link against a bunch of .lib files. I don't think Visual Studio should attempt to read any .LIB files if I want my code to perform dynamic linking is that correct? Or do I not understand the use of .LIB files enough?
thank you
How I understand, you are a little confused, because you want to use DLLs instead of LIBs.
The trick is that Kernel32.Lib, User32.Lib, AdvAPI32.Lib and so on has no implementation of the function which you use. Moreover if you use functions like CreateFileW or MessageBoxW in your program the references to the function will be unresolved after the compilation. So without having LIBs the unresolved references will stay also in the EXE. That will be bad of cause. To be executable the EXE must have resolved all external references and moreover know exactly which functions should be found in which DLLs. So named import library help to solve the problem. The import library Kernel32.Lib for example has information about CreateFileW function and User32.Lib has information about MessageBoxW. If you use a list of import libraries like Kernel32.Lib, User32.Lib, AdvAPI32.Lib your EXE resolves all referenced and includes the exact list of DLLs which it need and the list of functions used in the corresponding DLL in a special Import table (see http://en.wikipedia.org/wiki/Portable_Executable#Import_Table, http://msdn.microsoft.com/en-us/library/ms809762.aspx and http://www.microsoft.com/whdc/system/platform/firmware/pecoff.mspx). So If one starts your EXE the operation system loads the DLL in the address space of the process and resolves till the end all references up to the addresses of all functions used.
Typically import libraries will be created by linker (link.exe) when one compile a DLL. It is also possible to create an import library which corresponds to the DLL with respect of lib.exe utility. (see http://msdn.microsoft.com/en-us/library/0b9xe492.aspx)
As I recall, Visual Studio's compiler resolves .DLL files by linking against stub .LIB files.
Check, one of them should be kernel32.lib.