I'm working on a library project which is pretty much finished. So I'm giving it a test run now. I have no problem running my test project. However I'm not entirely sure if I'm doing it right. Mainly because I don't really understand what is happening exactly( at least im not entirely sure).
I've compiled both the DLL and Static library(.a). For my test project i'm using the Headers from my library and linking against the static library. I'm able to compile. But then It seems that I also need the DLL where the executable resides in order for it to run.
So to my understanding, I compile using the static library but I don't exactly embed it into my executable, therefor at runtime it's looking for the DLL?
My confusion comes from the fact that I read that static libraries are usually embedded into the executable. But doesn't that only happen if you specify that in the compiler options?
I'm rather confused about the relationship in my sittuation. Can someone clarify this?
Edit:
I'm using GCC.
Codelite as my IDE.
lib is static (cannot be dynamically linked at run time) at compile time. So you are correct that the lib is "embedded" in the executable. More precisely, the lib is linked to other object files that the compiler has produced to build the exe file. A lib cannot link to another lib, only an exe or a dll can link to a lib.
dll is dynamically linked by the exe while the exe is run. dll is like another exe, but its entry function is "dllmain" instead of "main". dll can be built with lib's just like exe. dll can also link to other dll's at runtime to interface with these dlls' functionalities. The interface to dll is defined by a def file.
As to why your project would need the dll, you might want to check the calls of LoadLibrary in your project.
Related
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 am new to C++ programming. There are 2 libraries in my program, one needs to be linked dynamically, and the other needs to be linked statically, how can I set this up in Eclipse? I am using
Eclipse CDT + MinGW + Windows 7.
Thanks.
It's not entirely clear what you're after here.
Most of static vs. dynamic is in the library itself, not how you link to it. You can have a static library, which is basically just a collection of object files, stuffed together into a single file, with a directory to tell what parts were originally which files.
You can also have a DLL. When you create a DLL, the linker will normally also create a link library for that DLL. This library basically just contains stubs -- enough information so the linker can insert a link to the DLL into another DLL or executable.
When you use a DLL, you basically have three options for how to use it:
The most common case: the DLL will be loaded as the parent executable is loaded.
delayload: doesn't load that DLL until/unless you actually use a function from it (handy if you have, for example, a special DLL that's only used under, say, Windows Vista or newer).
Explicit dynamic linking. Here, you don't tell the linker about the DLL or an associated library at all. You call LoadLibrary and GetProcAddress to load the library, and get a callable function address.
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.
Just curious, I was told that with dll files, you can make modifications to the dll without recompiling the whole application that uses it. On the other hand .lib files need to be compiled so the code can linked to the application as one.
So I know that the .lib files are turned into machine code. but what about the dll's ?? Are they turned into machine code upon the execution of the application ??
This could probably lead to easy hacking if not used right.
The dlls are still machine code. They're just dynamically linked in at run time (hence then name) so (if you don't change the function signatures) you don't have to recompile your main program to use a dll after it's been changed. A static library is physically part of your executable, that's why changes there require a recompile (or really, a relink).
DLLs do contain compiled machine code. The difference is that the linking between the application EXE and the DLL is done at runtime, instead of at (traditional) link time between OBJ and LIB files.
A DLL normally contains machine code. The point isn't that you can modify the DLL because it's source code, but that you can modify the source code for the DLL, re-compile and re-link, and as long as the interface remains the same, you can replace the old DLL with a new one, and the rest of the application can use the new instead of the old.
In reality, this frequently leads to problems, such as an application including code that depends on a bug in the old DLL. When/if you create a version that fixes the bug, it breaks the application. Google for "DLL Hell" for many more examples.
Simply put:DLLs can be swapped out post-compilation because they are physically separate from your exe. Lib and obj files, on the other hand, are
compiled into your exe, so that updating them
requires recompiling your app.
Dlls are effectively exes that don't define main().
When a DLL is linked to the main program, only the interface, i.e. classes, functions etc. it exports are linked by their signature. The actual machine code inside the DLL is loaded only on runtime, not on compile-time; that's why you can build your app with just the DLL's lib, and put the actual DLL where you'd rather have it (for example some shared DLLs folder or whatever).
You can then swap out this DLL with any other DLL with the same interface. That is how plugin-systems usually work, as each plugin is simply a DLL that conforms to a documented pre-defined interface, and the program just loads all DLLs of that interface it finds in some "plugins" directory.
The (possibly) confusing part here is that there are effectively two kind of .lib files:
a) libs for static linking. These put all their compiled code directly into the main app, and are a fixed part of the resulting .exe file.
b) libs for dynamic linking. These contain an interface for a DLL containing the actual code, which must be available to the app only at runtime (and if it isn't, it won't start, and simply tell you which DLL it couldn't find).
Btw: you don't have to specify which one of the libs you link to is what type, it does it automatically.
Also: Some applications are built as DLLs meant to being run inside some external environment. Webservices, for example, are implemented as DLLs with a specific interface, which are being run by an Apache/IISAPI/whatever server. This works similarly to the aforementioned plugin-system, but here each DLL effectively is the application.
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.