We use VS2012, and have a dll built with a dependency on runtime DLL (/MD).
This dll is used in many different projects, and cannot be changed easily.
We also have a small launcher executable that has to able to run on freshly installed systems, hence with no runtime installed. It is linked statically against the runtime (/MT).
Now this exe depends on the above dll.
As is, the exe does not built [1]. I have observed that building it by ignoring MSVCRT (/NODEFAULTLIB:"MSVCRT.lib") solves [1], but produces [2].
Adding the few symbols reported as errors in "force symbol references" (e.g. /INCLUDE:"_strncpy") makes the build succeed.
However checking the generated exe with Dependency Walker shows the dependency to the runtime DLLs [3] through our dll. I confirmed that the strings [3] are present in it. Trying to run the exe on a clean install of Vista fails (the error says a DLL from [3] is missing).
I fear that this is not possible, and I have not found any information that suggests that it is.
Can a statically linked exe provide runtime functions to a dynamically linked dll? If yes, how?
Thanks
Refs:
1>MSVCRT.lib(MSVCR110.dll) : error LNK2005: _sprintf already defined in libcmt.lib(sprintf.obj)
error LNK2001: unresolved external symbol __imp__strncpy
MSVCP110.dll, MSVCR110.dll
Yes, a statically linked exe can provide functions to a DLL. However doing so with the Standard Library functions is more trouble than it is worth.
You'd need to stop the DLL from building using its own copy of the runtime, using /NODEFAULTLIB. That will get you a bunch of link errors, since every part of the Standard library, as well as some vendor extensions, used by the DLL is now an unresolved external.
Each of these would need to be added to the EXE exports tables, using a module definition file. An import library would be generated during EXE linking. And then that import library would be supplied to the DLL to satisfy its externals, resolving them.
In the end, you would have only one copy of the runtime library, allowing your EXE and DLL to share library objects such as FILE* and the heap (so you could allocate in one and free in the other). But the DLL and EXE would be extremely closely coupled. Almost any change to the DLL could break the build, and require new exports from the EXE to fix it. You definitely could not ship updates to the DLL separately from updates to the EXE.
A much easier approach, that still keeps the DLL size down, would be to use delay-loading. This way, although the DLL still cannot load without the runtime redistributable installed first, the failure would not occur during process startup, and the EXE would have a chance to check for the presence of the runtime and install the redistributable. Or diagnose and handle failure of the DLL to load.
In an extreme case, the EXE could avoid using the Standard library at all, ensure the presence of the redistributable components, and then invoke the delay-load DLL for all complex logic requiring the Standard library runtimes.
In these latter cases because the EXE is not using the DLL version of the runtime, you can't share Standard library objects between EXE and DLL. But the coupling is much much looser. I think it's a tradeoff worth making.
We eventually changed our dll build settings to /MT.
I don’t know of any other way to solve the problem.
If your .exe needs to run on a clean OS, it can't depend on any DLL's that are dynamically linked because these DLL's (and thus the .exe) can't load without the runtime DLL's. Have you considered an app-local deployment? Then both the .exe and dll can be built with /MD.
It is possible to create a project that can build as either a DLL or a static library. The small launcher executable should link with the static library configuration of the DLL project.
Related
I'm reading about /MT and /MD, but I'm a little confused about it
HEAR is something I don't completely understand :
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
what does it mean?
If you link with /MD or /MDd your program is going to need the CRT dlls in order to run. typically they are called something like msvcp100.dll for the C++ runtime and msvcr100.dll for the C runtime. If you are deploying your application using an installer, you can add a package with these to your installer so the dlls are going to be there when someone runs the application. If on the other hand you are going to deploy your application just as a single stand alone exe, your users are going to need a copy of these dlls. The latest versions of these dlls usually come with windows itself (not the debug ones) but if your user is running an older version of windows it may not have the needed dlls.
Linking your application to the static version of the CRT saves this whole headache for the price that the exe is slightly bigger (since it contains the CRT in it)
If you do use /MT (Static CRT) you have to make sure that everything else that you statically link with uses /MT as well. otherwise you'll end up with an executable where part of the code uses the static CRT and part is still depends on the CRT DLL. Other than defeating the basic purpose not needing the CRT DLL, this can also cause other problems.
To make sure what DLLs your exe depends on you can use the dependency walker.
This question is regarding dynamic linking of libraries and usage of dynamic linking of libraries in application.
For example we are devloping an application using C++ using Visual studio environment.
Here for include header files we specify in Additional Include Directories, and
in Additional Dependencies: Mylibrary.lib
in Additional Libraries Directories: We specifies path of libraries
And in Windows we also have "LoadLibrary" API which is used to load dynamically linked ibrary.
My question is
when we include dll in Additional dependencies libraries why we should use "LoadLibrary" API?
When we should use "LoadLibrary" API?
Thanks!
LoadLibrary lets you continue program execution if the dll is not on the running machine. It returns an error status that can be checked and execution can be continued.
Also, linking lets you do stuff like use classes from the other binary & others. LoadLibrary only lets you find functions via GetProcAddress.
Imagine that you have a software that for example needes at a determined time to convert
Internet network address into strings.
On windows vista or later you can use the "InetNtop" function that is also able to deal with ipv6, but if you link directly to the DLL your program will no work on lower OS (ex: windows xp).
So the best solution would probably be making 2 DLL's one that used "InetNtop" and another that used for example "inet_ntoa".
Then your "main" program would do at runtime a LoadLibrary of the "InetNtop DLL", or the "inet_ntoa DLL", according to the OS that he his installed.
You asked that you can include dll in Additional dependencies libraries, and then why to use loadlibrary.
First lets clear the understanding:
While linking statically, A programmer is needed to add the .lib file to
Additional library dependency, which is linked to the caller program at compile time,
However, Dlls are loaded dynamically, hence you need not to add dlls in Additional library dependency when you are using LoadLibrary ie; if you are linking the Dll explicitly you are not needed to give your dll path in Additional library dependencies.
Please note:
using LoadLibrary you will be able to Get the Dll handle, which you can call the exported function using GetProcAddress.
refer:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
I have a dll that I distribute that will not run on some windows OS. Using dependancy walker I discover msvcp90d.dll missing on these systems. I DO NOT want any run time dependancies that require the C++ redistributable, and since the application that calls the DLL is not written in C++, it does not have any dependancy on the C++ redistributable.
I am guessing the I left the DEBUG option in the linker preferences on when I compiled the dll which is why it needs msvcp90d.dll?
ADDED:
Appologies, I pasted the wrong dll name in my original question.... too many hours in front of the monitor...
THe dll is a third party dll that I did not write compiled by me in VS2008.
MSVCP90 is nothing to do with debug (that'd be msvcp90d). You can remove your dependency by switching the compiler to /MT (instead of /MD). You also need to ensure that every static library you link to was also compiled /MT.
I recommend against building apps /MT because it has a significant negative effect on system performance and makes servicing take longer in the event of a security issue with the CRT.
Finally, note that /MT means that your CRT is private. So you must ensure that CRT/STL types don't pass across your DLL boundary.
Martyn
Your options as I see them:
Compile the DLL with the /MT option to use static linking to the C runtime.
Continue with dynamic linking to the runtime, but distribute the C runtime with your app.
It needs MSVCP90.dll because the dll was compiled with Visual Studio 2008 most likely. That is the release runtime. The short answer is if you don't want C++ runtime dependencies don't use C++ libraries or applications.
However you can do any of the following to solve your problem:
Install the redistributable to the target system to satisfy the dependency
Remove the dependency on that dll from your application
Recompile the dll against the version of VC you prefer that is already present on the target system
I know this may seem quite basic to geeks. But I want to make it crystal clear.
When I want to use a Win32 DLL, usually I just call the APIs like LoadLibrary() and GetProcAdderss(). But recently, I am developing with DirectX9, and I need to add d3d9.lib, d3dx9.lib, etc files.
I have heard enough that LIB is for static linking and DLL is for dynamic linking.
So my current understanding is that LIB contains the implementation of the methods and is statically linked at link time as part of the final EXE file. While DLL is dynamic loaded at runtime and is not part of the final EXE file.
But sometimes, there're some LIB files coming with the DLL files, so:
What are these LIB files for?
How do they achieve what they are meant for?
Is there any tools that can let me inspect the internals of these LIB files?
Update 1
After checking wikipedia, I remember that these LIB files are called import library.
But I am wondering how it works with my main application and the DLLs to be dynamically loaded.
Update 2
Just as RBerteig said, there're some stub code in the LIB files born with the DLLs. So the calling sequence should be like this:
My main application --> stub in the LIB --> real target DLL
So what information should be contained in these LIBs? I could think of the following:
The LIB file should contain the fullpath of the corresponding DLL; So the DLL could be loaded by the runtime.
The relative address (or file offset?) of each DLL export method's entry point should be encoded in the stub; So correct jumps/method calls could be made.
Am I right on this? Is there something more?
BTW: Is there any tool that can inspect an import library? If I can see it, there'll be no more doubts.
Linking to a DLL file can occur implicitly at compile link time, or explicitly at run time. Either way, the DLL ends up loaded into the processes memory space, and all of its exported entry points are available to the application.
If used explicitly at run time, you use LoadLibrary() and GetProcAddress() to manually load the DLL and get pointers to the functions you need to call.
If linked implicitly when the program is built, then stubs for each DLL export used by the program get linked in to the program from an import library, and those stubs get updated as the EXE and the DLL are loaded when the process launches. (Yes, I've simplified more than a little here...)
Those stubs need to come from somewhere, and in the Microsoft tool chain they come from a special form of .LIB file called an import library. The required .LIB is usually built at the same time as the DLL, and contains a stub for each function exported from the DLL.
Confusingly, a static version of the same library would also be shipped as a .LIB file. There is no trivial way to tell them apart, except that LIBs that are import libraries for DLLs will usually be smaller (often much smaller) than the matching static LIB would be.
If you use the GCC toolchain, incidentally, you don't actually need import libraries to match your DLLs. The version of the Gnu linker ported to Windows understands DLLs directly, and can synthesize most any required stubs on the fly.
Update
If you just can't resist knowing where all the nuts and bolts really are and what is really going on, there is always something at MSDN to help. Matt Pietrek's article An In-Depth Look into the Win32 Portable Executable File Format is a very complete overview of the format of the EXE file and how it gets loaded and run. Its even been updated to cover .NET and more since it originally appeared in MSDN Magazine ca. 2002.
Also, it can be helpful to know how to learn exactly what DLLs are used by a program. The tool for that is Dependency Walker, aka depends.exe. A version of it is included with Visual Studio, but the latest version is available from its author at http://www.dependencywalker.com/. It can identify all of the DLLs that were specified at link time (both early load and delay load) and it can also run the program and watch for any additional DLLs it loads at run time.
Update 2
I've reworded some of the earlier text to clarify it on re-reading, and to use the terms of art implicit and explicit linking for consistency with MSDN.
So, we have three ways that library functions might be made available to be used by a program. The obvious follow up question is then: "How to I choose which way?"
Static linking is how the bulk of the program itself is linked. All of your object files are listed, and get collected together in to the EXE file by the linker. Along the way, the linker takes care of minor chores like fixing up references to global symbols so that your modules can call each other's functions. Libraries can also be statically linked. The object files that make up the library are collected together by a librarian in a .LIB file which the linker searches for modules containing symbols that are needed. One effect of static linking is that only those modules from the library that are used by the program are linked to it; other modules are ignored. For instance, the traditional C math library includes many trigonometry functions. But if you link against it and use cos(), you don't end up with a copy of the code for sin() or tan() unless you also called those functions. For large libraries with a rich set of features, this selective inclusion of modules is important. On many platforms such as embedded systems, the total size of code available for use in the library can be large compared to the space available to store an executable in the device. Without selective inclusion, it would be harder to manage the details of building programs for those platforms.
However, having a copy of the same library in every program running creates a burden on a system that normally runs lots of processes. With the right kind of virtual memory system, pages of memory that have identical content need only exist once in the system, but can be used by many processes. This creates a benefit for increasing the chances that the pages containing code are likely to be identical to some page in as many other running processes as possible. But, if programs statically link to the runtime library, then each has a different mix of functions each laid out in that processes memory map at different locations, and there aren't many sharable code pages unless it is a program that all by itself is run in more than process. So the idea of a DLL gained another, major, advantage.
A DLL for a library contains all of its functions, ready for use by any client program. If many programs load that DLL, they can all share its code pages. Everybody wins. (Well, until you update a DLL with new version, but that isn't part of this story. Google DLL Hell for that side of the tale.)
So the first big choice to make when planning a new project is between dynamic and static linkage. With static linkage, you have fewer files to install, and you are immune from third parties updating a DLL you use. However, your program is larger, and it isn't quite as good citizen of the Windows ecosystem. With dynamic linkage, you have more files to install, you might have issues with a third party updating a DLL you use, but you are generally being friendlier to other processes on the system.
A big advantage of a DLL is that it can be loaded and used without recompiling or even relinking the main program. This can allow a third party library provider (think Microsoft and the C runtime, for example) to fix a bug in their library and distribute it. Once an end user installs the updated DLL, they immediately get the benefit of that bug fix in all programs that use that DLL. (Unless it breaks things. See DLL Hell.)
The other advantage comes from the distinction between implicit and explicit loading. If you go to the extra effort of explicit loading, then the DLL might not even have existed when the program was written and published. This allows for extension mechanisms that can discover and load plugins, for instance.
These .LIB import library files are used in the following project property, Linker->Input->Additional Dependencies, when building a bunch of dll's that need additional information at link time which is supplied by the import library .LIB files. In the example below to not get linker errors I need to reference to dll's A,B,C, and D through their lib files. (note for the linker to find these files you may need to include their deployment path in Linker->General->Additional Library Directories else you will get a build error about being unable to find any of the provided lib files.)
If your solution is building all dynamic libraries you may have been able to avoid this explicit dependency specification by relying instead on the reference flags exposed under the Common Properties->Framework and References dialog. These flags appear to automatically do the linking on your behalf using the *.lib files.
This however is as it says a Common Properties, which is not configuration or platform specific. If you need to support a mixed build scenario as in our application we had a build configuration to render a static build and a special configuration that built a constrained build of a subset of assemblies that were deployed as dynamic libraries. I had used the Use Library Dependency Inputs and Link Library Dependencies flags set to true under various cases to get things to build and later realizing to simplify things but when introducing my code to the static builds I introduced a ton of linker warnings and the build was incredibly slow for the static builds. I wound up introducing a bunch of these sort of warnings...
warning LNK4006: "bool __cdecl XXX::YYY() already defined in CoreLibrary.lib(JSource.obj); second definition ignored D.lib(JSource.obj)
And I wound up using the manual specification of Additional Dependencies to satisfy the linker for the dynamic builds while keeping the static builders happy by not using a common property that slowed them down. When I deploy the dynamic subset build I only deploy the dll files as these lib files are only used at link time, not at runtime.
Here are some related MSDN topics to answer my question:
Linking an Executable to a DLL
Linking Implicitly
Determining Which Linking Method to Use
Building an Import Library and Export File
There are three kinds of libraries: static, shared and dynamically loaded libraries.
The static libraries are linked with the code at the linking phase, so they are actually in the executable, unlike the shared library, which has only stubs (symbols) to look for in the shared library file, which is loaded at run time before the main function gets called.
The dynamically loaded ones are much like the shared libraries, except they are loaded when and if the need arises by the code you've written.
In my mind, there are two method to link dll to exe.
Use dll and the import library (.lib file) implicitly
Use functions like loadlibrary() explicitly
After going through a lengthy process to rename a project, my DLL project will not build in Debug mode (Release builds work):
MSVCRTD.lib(msvcr90d.dll) : error LNK2005: _CrtDbgReportW already defined in LIBCMTD.lib(dbgrpt.obj)
This project, and the five static libraries it depends on, are set to use "Multi-threaded Debug (/MTd)" (under C/C++|Code Generation|Runtime Library). I believe LIBCMTD.lib is the one for multi-threaded debug, but what is MSVCRTD.lib, and what could be causing this error?
If it makes a difference, this DLL is for Windows CE.
LIBCMT is what you need for /MT, MSVCRT is what you need for /MD. You are linking .obj and .lib files that were mixed, some compiled with /MT some with /MD. That's not good.
Usually it is the .lib files that cause the problem. Review their build settings and make sure their /M option is the same as your DLL project.
Also, beware of the trouble you can get into if the DLL was compiled with /MT. You'll have major problems when the DLL returns pointers to objects that the client needs to release. It can't, it doesn't use the same memory allocator.
The MSDN article on LNK4098 has a very useful table: it tells you which libraries to manually add to the "Ignore specific library" list, depending on which CRT you're using. In your case, you should ignore all of these:
libc.lib, libcmt.lib, msvcrt.lib, libcd.lib, libcmtd.lib
Observe that the reported library is in this list too. The problem is described in more detail in KB154753 ... libraries that a program will link with when built by using Visual C++
My interpretation of this is that in certain situations the algorithm that automatically picks which CRT libraries to link your code with will pick several conflicting libraries.
What is release set too? Setting a DLL to multithreaded debug can cause problems if you allocate memory that something accesing the DLL tries to free (they will be allocated in different heaps, for example). Try setting multi-threaded debug DLL.
Your link problem probably arises because a library you are linking to is expecting multithreaded debug DLL so the linker tries to link both and your link fails ...
The problem is the msvcr90d.dll is not in the windows ce image. It must be deployed with the application. The msvcr90d.dll is located in $(VCInstallDir)/ce/bin/$(ARCHFAM).
http://stackoverflow.com/questions/15959877/windows-ce-6-0-and-runtime-link-to-debug-dll-mdd