I have a third-party static lib, libTA.lib. It was built with /MT and I can't change that. I want to link libTA into a DLL I'm building, mydll.{lib,dll}. Of course my dll should be built with /MD; my dll will be used with /MD-built exes (also not under my control). Linking mydll with libTA.lib fails (correctly, I'd say) due to LNK2038, mismatch detected for RuntimeLibrary.
So, what can I do about this? Building mydll with /MT seems like a terrible idea because I don't want to have multiple msvc runtimes.
So my question is, what are my options? Anyone been through this before and found a solution?
Keep all the projects in your solution to /MD so that they will linked dynamically with external DLL libraries. The static libraries could be included in the additional dependencies or through #pragma include () directives. Note the DLL files should have their symbols exported through a .def file (use lib.exe to convert to lib file) or .lib file. However the toolset, target platform settings of all the dynamic and static libraries should be same to avoid linker error.
Related
I dont have visual studio 2008 installed.I am using 2012 and i rebuild this projects by cleaning.I checked the project settings and controlled the additional libraries and unfortunately I couldnt find any lib link has this name...in project just .h files of date_time are used but no lib linking. I configured new version of boost but STILL it wants this lib ? so is there any way I can solve this problem ?
With Visual Studio, boost use an auto linking system.
Special code in Boost header files detects your compiler options and
uses that information to encode the name of the correct library into
your object files; the linker selects the library with that name from
the directories you've told it to search.
date_time is one of boost modules that need a library (which is not header only).
So, you have to build them, using bjam (and --toolset=msvc-9.0), or retrieve them already built for your system.
Other option: disable auto linking. Just define
BOOST_DATE_TIME_NO_LIB
And link manually.
I'm building a dll on Visual Studio 2010, and I'm using some simple C functions like fprintf and fread, and it's linking to msvcr100.dll by default.
This dll is going to be loaded into an app that may be using a different CRT version (eg. msvcr90.dll, msvcrt.dll).
Since I know the app's going to load a CRT before my dll gets loaded, can I remove the dependency on msvcr100.dll and use the C functions in the CRT loaded by the app?
In the end, I decided to build the DLL against the lowest common denominator CRT version used by the target app, msvcr90.dll.
I did this by using the MSVC toolchain, available with Visual C++ 2008 Express (free).
I did try the mingw/gcc toolchain, which allows you to specify which CRT version to link against (see mingw-rt and gcc -specs=msvcr**), however, msvcr90.dll is a new-style SxS assembly so I couldn't get the produced executable to run properly.
It may be worth considering skipping linking against msvcr**.dll entirely; see this post and VC/include/delayhlp.cpp.
When you choose /MTd static linking in Visual Studio, would it try to link to each lib statically or there are some exceptions to system libs?
Description: /MTd: Defines _DEBUG and _MT. This option also causes the compiler to place the library name LIBCMTD.lib into the .obj file so that the linker will use LIBCMTD.lib to resolve external symbols.
From what I can see there is no static linking. If you want to do static linking you need to use ILMerge. And even then you should not attempt to merge in the required .Net Framework references as they often reference others which you may miss. It may not even be possible as they use GAC for referencing.
The /MT and /MD flags only define how the C/C++ runtime library is linked in. It has no effect on other libraries, system or user defined.
The system libraries, such as kernel32.lib, user32.lib, etc) are import libraries - there is no static library to link with.
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.
I'm trying to compile some code from a Windows API. It says that certain .lib and .h files must be included in the version of the Windows 7 SDK I am using. Visual Studio shows the .h files, but gives linker errors (L2019) when I try to build the project.
How can I check what version of the Win7 SDK I have, and how can I see if it includes the necessary .lib files?
Did you actually tell the linker that it should link the corresponding .lib file? The project templates only link the most popular .lib files, kernel32.lib, user32.lib etc. If you use an "unusual" API function then you must also tell the linker to link the import library.
Project + Properties, Linker, Input, Additional Dependencies. If you don't know what .lib is needed then look in the SDK documentation for the API function. The .lib file is listed at the bottom of the article.
Another thing you can do is use a #pragma in your source code to tell the linker to link with a .lib. For example:
#include <shlwapi.h>
#pragma comment(lib, "shlwapi.lib") // NOTE: need to link this .lib to get shell functions
Possible solution: Go to "C:\Program Files\Microsoft SDKs\Windows" and see if there is a version installed (or if that path exists at all).