I'm try to build a dynamic dll library on on windows using visual studio, but there are two file generated, one is dll file, another is .lib file;
My knowledege of using dll library is privode it to linker, I don't know what is ther purpose of .lib file, it has the same file extension as static lib, and it definitely is not static lib;
Does visual studio generate a .lib file when create dynamic dll library at all situtation?
Do I need to use the .lib file in my application?
How do I do use the .lib file in my application?
It has to do with the difference between "implicit" linking and "explicit" linking. The one sentence answer to your question is that that .lib file, often called a "stub lib" and officially called an "import library", is necessary when you do implicit linking but not otherwise.
In implicit linking, at compile time the compiler generates external function references for calls into the DLL, then the linker needs to link those to something: it uses the import library to help it do that. The linker treats these calls as special cases; it inserts code in the executable file for finding the DLL and for calling into the DLL for specific functions.
From the point-of-view of the programmer, implicit linking behaves like static linking except the DLL needs to be somewhere where the system can find it when the application is run or the system will pop up an error dialog at application startup.
Explicit linking means that it is the programmer's responsibility to find and load the DLL and to know what functions are in the DLL and how to call into them. See LoadLibrary and GetProcAddress for details. Explicit linking is useful if usage of a library is conditional or for applications with plugin architectures in which the actual DLLs to be used may not even be known at compile time.
In general though, if implicit linking does what you need, it is easier to just do it that way.
Related
So I'm working on some libraries for c++ to make a beginner's experience easier. I've put the libraries into a standalone dll and now i want to add it to another project. But the thing is after searching the internet for ages, i have to have include directories and stuff but all i want is to include the single dll file to the project so the project can access the .h and .cpp files inside. Ik i can just add external jar with java then i can access the libraries in there but how do i do it with c++ in visual studio 2015?
This is not how C++ works (I also assume you're not talking about C++/CX or MC++ - which strictly speaking are not C++)
The C++ language does not define an "Application Binary Interface" - an ABI, which allows linking between binaries. That's an implementation concern.
There are ABIs that support C++, such as COM and CORBA, indeed the latest one is WinRT - itself based on COM.
C++ differs from languages like Java and C# which mandate a runtime which does have an ABI: Java has its .class and .jar files while .NET/C# has its CLR Metadata contained within its assembly (.dll files - which are not the same thing as "real" DLL files).
Note that DLL files generated by the C# compiler are nothing like DLL files generated by your C/C++ compiler toolchain's linker - while they share a common outer format as PE (Portable Executable) files, internally they are radically different: CLR DLLs contain CIL, an intermediate bytecode, whereas "real" DLLs contain native, processor-specific instructions.
The general way to work with other libraries in C++ is to either use them in source-form (as .c and .cpp files included in your project), or as .h header files with .lib (static libraries) which are almost similar to reusable binaries, except they're linked ("compiled into- and merged-with") into your finished binary and cannot be replaced at runtime.
The other way is with Dynamic Linking which requires your runtime (i.e. Win32) to do the runtime linking for you, usually with GetProcAddress - but this only exports C-style functions, not entire objects and classes (and certainly not any C++ templates).
In summary:
You have a DLL and you want to use code inside of it:
Is it a WinRT DLL?
If you want to use pure C++ then you need to use WTL. Beware, this approach is not for the faint-hearted.
Else, if you're okay with C++/CX then you can actually use the "Add Reference" UI in Visual Studio, but be advised, you're no-longer writing "real" C++ anymore.
Else is it a COM library?
(Note that you will need the ATL (Active Template Library) and the IDL definitions of the types contained within, this is the COM equivalent of a header file). You can also use #import and/or use the IDE to generate the actual .h and .c files needed to call COM without too much pain. However you will run into problems if you replace the COM DLL later without rebuilding your program if too many things were changed in a later COM DLL version (see "DLL Hell").
Else is it a traditional native Win32 PE DLL?
All a PE executable has is a list of exported functions and their address locations within the DLL.
Do you want Static Linking or Dynamic Linking?
For Dynamic Linking, do you want runtime resolution (painful, but flexible) or "automatic" linking?
For runtime linking you only need the .dll file and .h files. You will need to manually call GetProcAddress yourself for each function you want to call, then invoke it. An advantage is that you can detect at runtime if a function exists and gracefully handle linking errors.
For automatic linking you will be given a .lib file in addition to the .dll and .h files, the .lib file is a small statically-linked library that contains stubs and other code needed to perform the runtime linking for you without needing to manually call GetProcAddress yourself.
For Static Linking you won't have a .dll file, but a .lib file: known as a "static library". Inside it's a file that contains discretised executable function blobs which your linker will effectively copy+paste into your completed program.
How do you do it like Java? Well, you don't.
A header is required to provide the compiler with the prototypes of the functions and other symbols that are exported from the DLL that you might want to make use of. You may even have multiple header files to logically divide your DLL's code. And since you won't want to hard-code the path to these header files in your source code, you'll want to specify the path to its containing directory as part of your compiler/build options, freeing you to use relative paths.
A LIB file is generally also required, although this is slightly more flexible. Generally, a LIB makes things much easier. It will be generated by the linker when you compile the DLL, and it contains stubs that facilitate linking to functions exported by that DLL. You specify this LIB file in your linker options when building an application that uses the DLL, and things just work. This is called implicit dynamic linking. It's dynamic linking because you're using a DLL, but it's implicit because the linker is handling the dirty work for you.
If you don't want to use a LIB file, you will need to do explicit dynamic linking. This is still dynamic linking because you're still using the DLL, but it's explicit because you have to explicitly write code to load the DLL module and obtain pointers to functions that it exports. Microsoft's build tools provide various features to make this easier, but it's still more difficult than just using the LIB file, which is what I would recommend unless you have a good reason to do otherwise.
I am perplexed by the concept between the run-time library option on Windows. I thought I know the difference between lib and dll. The lib will be compiled to your code and the dll will be loaded dynamically on execution. But when I compile a lib, I am obliged to make a choice between /MD and /MT. On msdn.microsoft.com it is said that:
Applications compiled with /MD are statically linked to MSVCRT.lib.
This library provides a layer of code that enables the linker to
resolve external references. The actual working code is contained in
MSVCRversionnumber.DLL, which must be available at run time to
applications linked with MSVCRT.lib.
At this time I cannot catch the idea that when I using a lib I also need to dynamically load a dll. It seems like that using /MD option to build a lib will result in a "dynamical lib", or using /MT option to build a dll will result in a "static dll".
So what's the difference between "/MD vs /MT" and "lib vs dll"?
A key aspect of this is differentiating between the build/compile time issues and the runtime issues.
At build time, the compiler and linker need sufficient information on how to compile and construct the code; data definitions, function locations etc. The header files provide most of that detail for the compiler, the linker needs to be able to locate the functions1 to complete the process.
If the dll is provided with a lib as well (as is the case with /MD), this lib contains the minimum required code for the linker to find the functions required and some additional code to load the dll at runtime. A program can be made that does not link with a lib (even though there is a dll), you will then need to load the dll at runtime (via LoadLibrary) and fix up the pointers (via GetProcAddress) to the functions1 you need to call. With a C++ library that is difficult, hence it is generally not attempted, the name mangling make this harder (with a C library it is generally much easier).
If the lib is a static lib with no associated dll (for the runtime this is /MT), then the lib contains all the code needed to run and execute its given functionality. The linker links all the required code up into the target and no additional runtime loading is required.
1 I loosely use the word functions here, but it includes all externals as well.
In both cases the application will be statically linked with a .lib file, but if /MT is used then it will be linked with libcmt.lib or libcmtd.lib (Release/Debug), which contain the C run-time itself, whereas if /MD is used it will be linked with msvcrt.lib or msvcrtd.lib, which are just import libraries for the DLL and do not contain the run-time.
See https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.120).aspx for details.
(Note that in VS2015 the libraries have been split and have new names; the C99-portion names are libucrt.lib, libucrtd.lib, ucrt.lib, and ucrtd.lib, respectively.)
Every DLL has a corresponding .lib file too. The linker links against the .lib file, which has the necessary instructions that indicates which symbols need to be loaded at run time from a DLL.
This is interview question.
Is it possible to link lib dynamically like a DLL ?
For example, for DLL, we use LoadLibrary and call exported functions.
Is it possible to use lib file in same manner?
No. .lib library are statically linked, and that is the purpose they're created for, to resolve the name symbols at link-time by Linker, and link-time occurs before runtime. They're often referred to as "static libraries" (that is why I added this tag in your question!). That is the brief story of lib.
However, you can create a DLL wrapper, if you really want to link at runtime.
No. Create a DLL instead or, if you do not have the source, wrap the functionality in the .lib with own DLL interface.
No. It's not possible. A DLL is module with a PE32 header with all information to load it into a process. A LIB is only a archive of OBJ files.
And despite others say it's easy to wrap a DLL around it, this can be quite difficult. The reason is, that a .LIB not only resolves some dependencies but can also have unresolved externals.
As long as these unresolved externals require only the compiler's runtime library wrapping in a DLL might work. You can check this when you create a DLL project, probably with a minimal C++ source, and try to compile. Than you see, if further externals must be resolved with other libraries.
One important problem may arise with memory management. When yo link statically with a .LIB you will use all the same definitions. If your library comes with own implementation, let's say of malloc-stlye functions, this will not be linked to your application as long as you add all these symbols to the EXPORT list. Finding the list of public symbols that should be included in the EXPORT table may be a pain.
Yes - not directly, but with a very small amount of work.
Create a new .DLL project, link the .lib, define which functions you want to export in a .DEF file then compile.
I have a framework (in C++) which is dependent on a few third party libraries. When I compile a static version of the library framework, no additional dependencies are needed, that is, the lib files of the third part libraries are not needed. When I compile the same framework as a DLL, additional dependencies are now needed otherwise I get linking errors. I can guess as to why this is happening but would like a concrete answer/explanation to understand what is happening.
EDIT: Just to clarify, I am developing a framework which can be compiled as a lib and as a dll and then used in a(n) (executable) project. When compiling the framework as a lib and using functions from a third party library, I don't need additional dependencies. However, a project that now uses the lib file (which is the framework) must include the 3rd party lib files. When I compile the framework as a dll it gives me linking errors unless I specify the 3rd part libraries the framework is technically dependent on. For example: I have a few classes that call functionality from within Ogre3D. These classes are compiled as a lib file. I don't need to link against OgreMain.lib when compiling a lib of the classes. On the other hand, when I am compiling a dll version of the same classes, I now need to link against OgreMain.lib
When you have a static library (a .lib file), which is just a collection of one or more object files (.obj), the linker just adds that code to yours in one executable. You can tell the linker to do this via a command line switch, an IDE configuration setting, or perhaps even a #pragma (specifics depend on your environment and compiler).
When you link in a DLL, you need to give the linker some code to call when you invoke one of the DLLs functions. Usually, this is done with a file of the same name as the .dll, save that it is a .lib. The code in that .lib is linked into your program the same way as described above, but when you call it, it loads the DLL (if not already loaded) and then invokes the proper function.
There are other ways to handle DLL linking (for instance, .def files or #using statements in .NET), but this seems to be what you're talking about.
Responding to your question clarification:
The issue is that a .lib is not a final product. It is just an aggregation of object code to be used later when a linker connects all your functions calls to function addresses.
A DLL, on the other hand, is a final product, and so the linker requires all functions and variables be connected to actual addresses.
I'm speaking a bit imprecisely, but you get the idea.
A static library can include other static libraries, providing a single lib to link
A DLL can include static libraries, providing a single DLL to link.
A DLL or static library with dependencies on other DLLs has no way to combine them so your executable must explicitly link to those other DLLs.
When you link to a LIB it adds all the symbols/functions you actually use to your executable. The ones you don't use won't get added. When you link to a dll - all the code from the external library gets loaded. If this additional code (code you don't use) depends on more external libraries you need to provide these as well.
One example: You want to use a ip class from a network library. The ip class does not depend on other libraries. Other functions in the network library depend on other external libraries. If you link the network library as a LIB you just link the ip class -> you don't need the other libraries since the other code wont get linked. When you use the DLL all code in the dll need to be instanciated -> so you will need to provide the other external libraries.
Building a DLL is more like building an application than a library. The difference between building an application and a DLL is knowledge of what might be called. In an application all symbols that are not used can be discarded in the build, but in a DLL you cannot strip symbols that are not used - that would be all of them...
You would find the same link problems in your static libraries if you where able to call all the symbols that the DLL links.
It's pointed out by this answer:
Failed to link mysql5.1.39\bin\libmySQL.dll
But I don't understand why,.dll is essentially the same as .lib except for there is only one copy of it used by different processes.
Does it have anything to do with the IDE?I'm using visual c++ 2008 express
UPDATE
Anyone know a free tool to convert .dll into .lib in windows?
You are wrong on two counts. Firstly, DLLs and LIBs (static libraries) are very different beasts. The LIB you are talking about (I think) is the export library, which is simply a list of names in the DLL. This library is typically produced when the DLL is compiled and is shipped with the DLL if the DLL is intended to be linked to by other developers.
To use a DLL with a modern IDE (I don't use VS) you typically include the matching .LIB (export library) in the project. At run-time you must make sure the DLL is available to your program - the simplest way to do this is to put the DLL in the same directory as the executable.
And secondly, DLLs can be used with C++.
DLL are specific windows executables which load on runtime. Their equivalent in Linux is the *.so .
If you want to understand what's the difference between a DLL and a static lib see here.
Main reason has probably something to do with dll-file being an output of the linker (link.exe). This command line utility doesnt know how to read dlls, only how to write them.
Actually sometimes .lib-files contain more than a list of functions. For example libpng.lib works as a standalone file, without any dll file.
In order to use a DLL in C/C++ you need to link with what is called an import lib. This is a small .lib that contains the names/ordinals the DLL exports in a format that the linker understands. Once this has been linked in, the resulting binary will be able to use the DLL. If you do not have the appropriate import lib, your C/C++ compiler should come with a tool to generate one from the DLL.
You can use the following analogy to understand the difference between a dll and a lib file.
the dll is like the source .cpp file while the lib is the header .h file.
While this is not exactly true, the DLL holds the executable code while the LIB file tells the linker how to glue the code together.
It is also possible (in some cases) to generate the lib from the dll. Basically, all you need to know to call a function is the function entry point in the dll, the number of parameters and the size of each parameters. Sending relevant information is then your own problem.