I am building a dll project. I am using openssl and quickfix libraries. I don't want users to separately copy the libraries when they use dll. I want to bundle these .lib files into my dll as well.
I am using visual studio. How can I bundle these libraries(.lib static libraries) into my dll so that the user can just copy my dll into their projects and start working right away.
Thanks,
by default it'll be bunded in. you program, just call it MyProgram.DLL, can
call other programs, as a DLL file, e.g. C Runtime Library provides
MSVCRT.DLL for MyProgram.DLL to call; or
include other program's Static Library file, i.e. the .LIB files, inside your binary, i.e. MyProgram.DLL, e.g. C Runtime Library provides LIBCMT.LIB for MyProgram.DLL to include inside and call.
It seems you want option 2), but actually, since what provided are .LIB files, option 1) is not possible for you.
Related
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
I want to use the functionality of a 3rd party dll into a lib I create.
Something like this:
m_hLib = LoadLibrary(L"Bla.dll");
and the using this with:
void* fnBla = ::GetProcAddress(m_hLib , "MethodFromBla");
to use some stuff from the respective method.
Now my question would be: could I build the lib like this and then use its functions from an exe?
No Problems at all . exe gets statically linked to the lib file . That means lib code becomes part of exe code . Now the exe code is loading the dll dynamically :)
What you're doing is dynamic (or runtime) linking, ie you explicitly load the .dll and resolve the functions via GetProcAddress. If you're doing this then you don't need a .lib file.
A .lib file is only necessary if you want to statically link against the .dll at compile time. The linker takes the .lib file and resolves the references in your program against the functions information in the .lib. Therefore, if you don't plan to link to the .dll at compile time you won't need a .lib. You just need to make sure that the .dll (Bla.dll in your case) it released alongside your application.
There are things that I don't understand when it comes to linking... I'm writing a program using a 3rd party library (the GEOS library). This program has a dependency to geos.lib but still needs geos.dll to run.
I read this question, I think I understand the difference between static and dynamic libraries. What I don't understand is why I still need a dll when I statically link a library.
There are 3 kinds of libraries on Windows:
object library (*.lib)
import library (*.lib)
dynamic library (*.dll)
object libraries are statically linked. They contain the full object definitions of the code abstracted by the library.
import libraries is a special form of an object library. Instead of containing code they contain information for the linker that ultimately maps the executable file to the dynamic-link library.
dynamic link libraries, like object libraries, supply code for your program. However, this code is loaded at runtime and not compiled into your exe.
You don't always need to link an import library. Instead you can call LoadLibrary() and lookup the API entry points by name or ordinal. (You always have to tell the code which DLL and where in that DLL's API you want to enter.)
The other comments here are correct in that you cannot make a DLL into a static lib without recompiling the code for the libary -- it is a different kind of output.
It's not statically linked. The .lib is just a stub library that binds in the .dll on windows. That is, you link with the .lib at compile time, and then at runtime it will go looking for the .dll.
If .lib was created by Visual Studio then check value of Project properties -> Linker -> Input -> Module Definition File. If it's not empty then link.exe create stub library instead of static library even if Project properties -> General -> Configuration Type is "Static library (.lib)".
You are definetely linking to a dynamic library.
Just because the linker requires .lib file doesn't mean you're linking to a static library.
You can statically link the lib file if and only if this is a static lib file. So first you need to convert your dll's project to the static lib, build it and after that use the product of your build which will be a static .lib file.
A library can be used in an application in two ways:
Statically-linked
Dynamically-linked
But how to do that using both Visual Studio (windows) & GCC?
I know libraries are distributed only in these 4 ways:
Source
header-only libraries
*.lib files for windows. *.a for linux
*.dll (windows) & *.so (linux).
Source distribution is just compiled."header-only libraries" are nothing but a source distribution.
Now if the desired library is distributed in *.lib form. Inorder to use it.
On Visual Stuido :
We add directory path containing headers(*.h) to Configuration Properties > General > Additional Include Directories
we add each *.lib file to Configuration Properties > Linker > Input > Additional Dependencies
we add directory path of *.lib files to: Configuration Properties > Linker > Additional Library Directories
How to do the same thing for GCC/MingW?
I don't know how to build my application when the library is distributed as *.dll or *.so too. Can someone tell me what do I need to do in these situations for both Visual studio (windows) and GCC(linux)/mingw(windows)
On GCC, for static linking, you'll include the library in the command line. Lets say you've glib-2.0.lib and your program that uses GLib library is my_prog.c, then you invoke GCC as
gcc my_prog.c -L<library_dir_here> -lglib-2.0.
As for the dll and so, dynamic libraries are something you don't link to your programs by passing them to your linker. Instead the operating system gives you a function to load them when it's required, at run time. Thats the reason it's called dynamic. In Windows you've LoadLibrary and on Linux you've dlopen. Both these functions get a string (which is the dll or so's name) and load it if it's avaiable on the machine. Once it's loaded, the function you require from the library is looked-up by passing its name to GetProcAddress on Windows and dlsym on Linux; both returns a function pointer, with which you can call that function. Since you're not directly calling the functions provided by the libraries directly, but thru' function pointers, there'll be no need for you to link them statically (i.e. pass them to the linker) when you build your app.
For DLL distributions the scenario is similar to that of .lib files. (your #3)
You will have to configure your project to build a DLL. The project will build LIB and DLL files.
Depending on your needs/architecture/design you can either
Link against the LIB file just as you do in your #3 above. Note that the DLL file will have to exist on the target machine at run-time otherwise the application will not load.
Call "LoadLibrary()" from the client app and skip the linking part/no need to have the LIB used in the client application.
I can't help you with the gcc specific questions.
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