I have some confusion about static and dynamic linked libraries and .lib and .dll files.
I have a project with two libraries, one I built myself and one is from an open source library.
The one I built myself is a separate project in the same solution (Visual Studio 2015, C++), and I don't need to copy over the .lib files or create a DLL for the executable to build and run
For the other open source library, I do need to copy over the .lib file and the DLL into the executable folder. However, I thought it would be possible to statically link a .lib file and not have to copy over the DLL.
Does this mean I need to compile the Open Source library differently? Like change the define __declspec(dllexport) to __declspec(dllimport) ? Or change /mD to /mT in compiler options?
I tried both of these, but it's still saying that it can't start without the .dll
Or can I get away with changing a setting in the executable project to link this library statically? If so, what are these settings?
EDIT: I know this is a standard question that can be looked up on google, but I haven't been able to find an exact answer for a while. Mainly, I'm confused about what settings need to be changed, and which project they need to be changed in. (The library or the executable).
I'm under assumption that static linking means the library is built into the executable, and dynamic linking means the library needs to be in a separate file, if this is incorrect, please let me know. Otherwise, I need to know how to build the library into the executable file.
And I can go ahead and change the build options in the open source library, and I tried this already.
Thanks,
-D
In Windows, dll files (dynamically linked libraries) need to be in the same directory as the application or on the search path. lib files (static libraries) need to be statically linked during linking (the last step of building the application). It's common in Windows so have a library come with both a dll and lib file. In this case, the lib file is an import library containing the information needed to easily link to the dll.
Place the dll file where your application will be built and statically link with the lib file. Go to 'Project->Properties->Link->Input->Additional Dependencies' and 'Project->Properties->Link->General->Additional Library Directories' to specify the static libraries you want to link.
Edit: It seems I misunderstood the question. The question is how to recompile a dynamic library as a static library. You need the source code of the library you are using along with it's Visual Studio Project file. Open the library and in `Project->Properties->General->Configuration Type' change it from Dynamic Library to Static Library.
Beware that Dynamic Library uses the Linker group of properties while the Static Library uses the Librarian group of properties. Changing between these types may cause the project to drop essential linker flags options. Since every library is different, I can't predict what you will have to do work around this. Make sure to backup the project file so you can see the original options and flags.
I had to change the setting for "Static Library" for All Configurations, not just Debug, although it was building in Debug. Not sure what may have caused this. Possibly because the debug and release builds for the library were set to the same folder, it may have been overwriting the debug builds with release builds when building
Related
Probably I am missing here something but that is my first time on Windows that I need to link a lib statically so that the executable won't be dependent on a dll.I do it with LIBPNG.
I do it like this:
I added libpng headers : C/C++ -> Additional Include Directories
Added library directory to the linker: Linker - > General ->
Additional Library Directories
Added linker additional dependencies:Linker -> Input
Compile the exe ok.When calling it I am getting :
"The program can't start because libpng16.dll is missing from your
computer."
Which means libpng hasn't compiled into the executable.How do I fix that without reference the whole pnglib project code into my executable project?
On Windows a .lib is a library file, usually this simply contains code that loads a dll, looksup the exported functions and provides wrappers to them. But, you can build the lib differently so that instead of these wrapper stubs, it contains the actual binary code. The operation and structure of the .lib is the same - what code it contains depends on how its built.
So, if you've built libpng16 as a 'dynamic' lib/dll pair then you will need the dll part when you deploy it. If you built it as a 'static' lib only, then you'll get what you want.
The point is - you need to build the lib in the format you want in the first place. It is not possible to take a lib/dll pair and convert it into a static lib, nor is it possible to merge a dll into your executable. (well, not possible after you've built it - perfectly possibly if you change the lib's settings and recompile to produce in static lib form, of course)
I implemented the SFML library nightly build to my Visual Studio 2013, because the original one is not compatibile with this VS version. I done everything what is needed (added directory to include folder in both Debug and Release, added directory to .dll files), but it can't find the files in program. What else should be done to make this library work? Or should i consider changing Visual Studio to 2010?
You haven't given really to much information so I am just really guessing as to what the problem is.
added directory to .dll files
But that sounds like your problem right there. You don't add the directory that the .dll files are in to your project. The only directories you need to add to the project are the include directory and the library directory.
But anyways I am assuming you are using dynamic linking since otherwise you wouldn't be dealing with .dlls. Now different IDE's require that you place the .dlls in different spots but since you are dealing with VS2013 you need to copy whatever .dlls that you are using into the same folder where your program's compiled executable is (The .exe file).
Another option is to link statically instead of dynamically which I generally prefer to do on small projects but it is really up to the developer which he prefers.
When you link statically you don't need to include any .dlls. What you will need to do is recompile SFML's sources and make sure to build the library so it produces the static library files (They should be named something like sfml-graphics-s-d.lib for debug and sfml-graphics-s-d.lib for release).
Add that library directory which contains the static library files to your project and then link to them .lib files in VS's input window (Remember that -d is for the debug build).
Next you will need to add SFML_STATIC to your preprocessor options on both the release and debug build.
After that you are good to go and don't need to include the .dll files with your project. And again whether you choose to link dynamically or statically is really up to you and the project you are working on but for small projects I would suggest linking statically.
I'm linking to a few libraries in VS2008. If my knowledge of the linker is correct, MTd is for static linking and MDd is for dynamic linking (to a DLL.) My goal is to statically link some libraries and dynamic link others. The project options seems to only have one setting for all libraries in the linker input. How would I do this?
Your project will be given a sensible C Runtime Library default after you set it up, depending on how you answer the New Project Wizard prompts. You can inspect and alter this (if needed) as follows:
right-click the relevant project in Solution Explorer, select Properties
look under Configuration Properties, C/C++, Code Generation, Runtime Library.
Other libraries can be linked however you want, you just specify the library to link to under Linker, Input, Additional Dependencies.
Even if you are linking to a DLL, it will still have a .LIB file (of the correct form for a DLL) to resolve external references, unless you are manually loading the DLL and discovering required function entry points.
You do need to make sure that the LIB files you link to use the same CRT as your app does, or things can go unexpectedly wrong.
No, you're mixing it up. The /MD vs /MT options is only relevant to which CRT version you link. There are two, the static version (/MT) which you should use only if you don't use any DLLs in your project. And the DLL version, a version that every binary in your process can share so that you won't have heap allocation misery. The kind of misery you get into when memory is allocated by one module and freed by another.
Choosing your own libraries is entirely up to you. Mixing and matching is fine, the linker just gets another kind of .lib. An import library instead of a static library. Just keep in mind to use /MD when you use DLLs.
The linker options your describing are for the CRT only. The static version will limit how you share memory between modules.
All other libraries you use will have be linked in based on the .lib files you provide(or not) to the linker.
There are 3 ways to use a MS library
statically link static library (.lib equivelant of an .a archive of .o)
statically link the stub (.lib compiler generated loadlib/getproc) of a dynamic library
manually load a dynamic library (loadlib/getprocaddress)
I have a dll and an exe, both of which I have the sources to.
For the DLL I have compiled completely statically and therefore, I would assume that the the .lib is also static. However, when I include that lib in my C++ VC++ 2008 project under Linker > Input > Additional Dependencies . I set the compile mode to /MT (multi-threaded) for the exe.
Everything compiles, but when I try to run the exe, it asks for the dll! To the best of my (limited) understanding, that shouldn't be happening.
Why should I do?
The 'compile mode' setting that you are referring to is the setting for the runtime library that gets linked with whatever library or executable you produce.
If your project is set up to produce a DLL (check the main project page), then it'll still produce a DLL no matter what you're putting into the runtime library setting. What I think you want to do is change the setting on the DLL's main project page from DLL to Static Library instead of changing the runtime library setting.
Once you've done this, make sure that both the executable and library projects have the same runtime library setting (the /MT switch you refer to), otherwise you'll get tons of strange error messages if the linker is trying to match up two different runtime libraries in the same executable.
The .lib file that is created with a "static" DLL is just an import library that handles automatic dynamic linking to all the symbols in the library. The DLL itself (that is, the .dll file) still contains all the code/symbols/etc. that you expect.
Statically linking to the .lib file just saves you from manually calling LoadLibrary()/GetProcAddress(), etc. to resolve symbols within the DLL.
You'll still need the DLL itself unless you build a true static library (that is, with all the symbols & code, rather than just the imports).
I'm new to C++ and there's something I just completely don't get. In C#, if I want to use an external library, log4net for example, I just add a reference to the log4net DLL and its members are automatically available to me (and in IntelliSense). How do I do that in non-managed C++?
Often, the library comes with 1) a header file (.h) and 2) a .lib file in addition to the .dll.
The header file is #include'ed in your code, to give you access to the type and function declarations in the library.
The .lib is linked into your application (project properties -> linker -> input, additional dependencies).
The .lib file usually contains simple stubs that automatically load the dll and forward function calls to it.
If you don't have a .lib file, you'll instead have to use the LoadLibrary function to dynamically load the DLL.
The basic concept is the following:
There are 2 types of libraries: static & dynamic. The difference between them is that static libraries, during the linking build step, embed their compiled code in your executable (or dll); dynamic libs just embed pointers to the functions and instructions that some dll should be loaded when program is going to be loaded. This is realized for you by the linker.
Now you can decide which of those two you are going to use. DLLs have many advantages and disadvantages. If developing a huge application it might be worthy to consider using DLLs with delay loading instead of static lib's. Some libs are simply delivered to you as DLLs and you have no choice. Anyway the easiest way for a beginner would be to use static libraries. That would make your deployment and test much easier, since, when dealing with DLL you have to ensure that they are found at runtime (even when using debugger), this involves either copying everything in one directory or dealing with path variables.
Usually a DLL provider (if it is intended that you should be able to deal with the library) delivers you a header file(s) and a .lib which contains the calls into the desired DLL. Some vendors (e.g. boost) only require you to include the header file and the lib is automatically linked to your executable (can be achieved through compiler prorietary pragma directive). If it is not the case you must go into the project settings of the C++ project (project properties/Configuration Properties/Linker/Input) and enter the lib file name into the "Additional Dependencies" row, e.g. iced.lib; iceutild.lib. You can also put fully qualified path names there. Be aware that you have to enter the lib file names for both configurations (Debug, Release). This is the procedure you do with static libraries and Dll equally. The only difference that DLL will require a DLL lib to be either in you app-directory or in one of the path-directories.
After that step, you still might get compiler errors if you try to link incompatible libraries. There are many reasons, why they can be incompatible. But try to first link the lib this way and see if works. If not, post again your errors here ;)
Include file(s) is(are) used to be included in places, where you would like to use smth. from the lib. Just include it and the compiler will know that the symbols must come either from another (compiled) compilation unit (compiled cpp-file=>object file) or the .lib. It will make the look up and notify you if the required symbols are not found.
Good Luck,
Ovanes
P.S. This might be hard in the beginning, but when you get used to it, it will be easy.
C++ doesn't have libraries in the sense you're thinking of. It has header files that you #include, and it has things called libraries that the linker deals with, which contain the compiled code. You need to add the libraries (.LIB files) to the linker settings.
On Windows if you're using a DLL, ideally you should have a .LIB file to go with it that is called the Import Library for the DLL, and you add that .LIB file to your linker settings.
The first thing you need to do is to #include the header file that describes the functions that are available in that library.
The actual code for the library will be in one of 2 places:
A static library (.lib)
A dll (.dll)
Depending on how the library's code is given to you (as .lib files, or as a .dll), you'll have to either:
#pragma comment( lib, "libraryname.lib" ) if its a .lib
LoadLibrary if its a .dll
Sometimes a package comes with BOTH a .lib file that you need to link to, and a .dll file. In this case you don't need to call LoadLibrary, you only need to #pragma comment( lib, "libaryfile.lib" ) because in this case the .lib links you into the .dll.
A very important detail is to put the DLL where your application can find it. Charles Petzold says:
When Windows needs to load a DLL module before running a program that requires it, the library file must be stored in the directory containing the .EXE program, the current directory, the Windows system directory, the Windows directory, or a directory accessible through the PATH string in the MS-DOS environment. (The directories are searched in that order.)
Programming windows, 5th ed
MSDN
I don't recommend using the project properties menu to link because it isn't as visible what libraries you're linking to.
See also