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.
Related
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.
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've knowledge of C++ and compiling small plug-ins (always based on a similar and laid out workflow). Though currently I need to compile the latest version of FFTW into a static library (or get it from the compiled version which should supposedly be a lot easier) and it's giving me an insanely hard time. Probably because I don't know the ins and outs of compiling. As a note I'm working on Windows with Visual Studio.
Since I really want to know how this should work I'm asking the question here.
Basically I need a static .lib of fftw3f library on Windows that I can include in another Visual Studio project.
The first I did was download the 64 bit dll's of FFTW from the website (hoping I could use this).
http://www.fftw.org/install/windows.html
Then I've done the accompanying step they stated, that is:
Run the following in lib.exe.
lib /def:libfftw3-3.def
lib /def:libfftw3f-3.def
lib /def:libfftw3l-3.def
I've done this as well and got a .lib file that I could use in my project correctly. I've been able to compile my project, yet the output build apparently dynamically linked to the library instead of including it as a static library.
I'm compiling my project to .dll but require the fftw3f library to be statically included in my output.
Using lib.exe /list libfftw3f-3.lib I was able to find out that the lib file was referencing the libfftw3f-3.dll.
According to my google results this would mean the .lib file that I created is a DLL import library instead of static library.
It's hard to figure out how to phrase my question because I'm not sure what the terminology is and what's going on behind the scenes. I guess:
How can I use the libfftw3f-3.lib file created from lib.exe as a static library in my own project. So that it is included in my output .dll instead of dynamically linked?
Based on what I learn from comments/answers I'll be happy to update/edit/rephrase my question to make more sense for most other users as I'm likely way of with the terminology
You cannot expect to convert a DLL into a static library.
In order to create a static library you need to re-compile the library from its source code, with an output target that is a static library. If you cannot obtain the source code, then your goal cannot be achieved.
I'm a little confused by what I've learned today. I hope somebody can help me out.
I understand the concept of dynamic and static linking, but the problem is as follows. On windows, or at least the paradigm on windows, you can have a .lib (which is like .a) and .dll (which is like .so, except... different) and you must statically link in the .lib which contains code that calls functions from the dll at runtime. Is this correct? In other words, gcc or g++ must have .lib files available at compile/link time, and be able to find .dll files at runtime. Please correct any wrong assumptions here.
However, I'm splitting a few of my source files in my small application away because I want to make them a library. When I run g++ on my object files, with the -shared option, this basically creates a shared library (.so)? This is where the confusion arises. The same so file is needed both at link time and runtime? I have trouble understanding how I need it in the -L/-l option at link time but it still needs the file at runtime. Is this actually the norm? Is a dll fundamentally different?
Finally, a final question. Take a library like boost on Windows. I built boost according to the instructions. In the end, the stage/lib directory contains libraries in a repeating sequence of name.a, name.dll.a, name.dll. What is the purpose of this scheme? I know I need the dll files at runtime, but when I use the -L/-l option at link time, what files is it using THEN?
Sorry if this is really scattered, but I hope someone can help clear this up. Thanks a lot!
On windows, or at least the paradigm on windows, you can have a .lib (which is like .a) and .dll (which is like .so, except... different) and you must statically link in the .lib which contains code that calls functions from the dll at runtime. Is this correct?
Yes and no. That is one way that DLLs work on Windows, but it is not the only way.
You can load a DLL manually, using Win32 API calls. But if you do, you have to get function pointers manually to actually access the DLL. The purpose of the import library (that static library you're talking about) is to do this automatically.
The nice thing about doing it manually is that you can pick and choose what DLLs you want. This is how some applications provide plugin support. Users write a DLL that exports a well-defined set of API functions. Your program loads them from a directory, and they bundle the function pointers for each DLL into its own object, which represents the interface to that plugin.
GCC works the same way, on Windows. Building a DLL produces a DLL and an import library. It's a ".a" file instead of ".lib" because of the compiler, but it still does the same thing.
On Linux, .so files are a combination of the .dll and the import library. So you link to the .so when compiling the program in question, and it does the same job as linking to the import library.
It's just two ways of giving infos at compile time about the shared library. Maybe a comparison would explain it better ?
In Windows, it's : "You will use a shared library (.dll) and here (.a or .dll.a) is the manual on how to use it."
In Linux, it's :" You will use a shared library (.so) so look at it beforehand (.so) so you'll know how to use it."
I know that if I have an .a or .so file and a header file for that library (for example for SystemC), I should
1. include header file
2. link the appropriate library.
But I can't handle with only .dll file as I can link it as well, but don't have a hearer file to include and to use commands. Con someone explain me what kind of .dll-s exist and how they are possible to use? Is it possible to use any .dll file or it should be a specific kind of .dll to be able to integrate to my application?
A DLL is functionally equivalent to a .so file (also know as a 'shared object' or 'shared library'). You need a header to declare the functions that are available inside the DLL and you need to link against a library which handles the business of loading and executing DLL calls (mostly delegated to the OS).
It is possible to use a DLL without any sort of header. You can directly call Win32 API's which will dynamically load a DLL into your programs virtual address space and call other API's which will give you what are essentially function pointers. However, you need to know the signatures of the function pointers to use the properly so what you're effectively doing in that case is declaring a tiny subsection of the actual DLL header for your use.
This wikipedia article may help, especially the section on shared libraries
Unlike Linux, Windows libraries are seperated into two forms: DLL (for runtime linking) and LIB for symbol declarations. link.exe (the windows linker) expects .lib files to resolve symbols being used by your program's headers during build time. More information here:
http://msdn.microsoft.com/en-us/library/ba1z7822(VS.71).aspx
Note that if you load a DLL compiled in C++, you hvae to avoid passing object pointers across the interface, as they are in general not portable. You have to keep to basic C calls and calling conventions, as that is what is defined by the Windows or Linux platform ABI.