I have a program that uses libcurl library. After code compiles in order for the .exe file to work I have to put libcurl.dll in the same folder as exe file. Is there a way to add this libcurl.dll file implicitly into the .exe file so it would not require the dll file?
You can add any payload to an executable image as a custom resource, including other binaries (see Creating a New Custom or Data Resource). During application startup you will have to extract the .dll and save it to disk. This also requires that you mark the library imports as /DELAYLOAD (see Specifying DLLs to Delay Load). Otherwise the loader will fail due to unresolved imports.
A more natural solution to your problem would be to compile cURL as a static import library and link to it statically. This compiles the libcurl code into your final executable image. Instructions on building a static library can be found at How to build cURL static library with SSL support on Windows.
You could try using open-source pefrmdllembed to merge the DLL into your EXE file.
Commandline: pefrmdllembed.exe -impinj myprogram.exe libcurl.dll myprogram_withcurl.exe
It will generate new "myprogram_withcurl.exe" that you can ship instead of the original EXE. Should work witb most DLLs.
Related
I've downloaded and compiled zlib, and I am statically linking zlibwapi.lib to my C++ project on Visual Studio 2015.
However, if I don't use the dll and launch my program, it complains about it:
"The program can't start because zlibwapi.dll is missing from your computer."
With the DLL though, no error message shows up and the program works fine.
Is there any way I could use my program without the need of zlibwapi.dll?
I've done this with MSVC 10. I created a separate project for zlib and built it as a static library (.lib), which I then added to my main application project. The projects are not in the same workspace. I did have to build a separate copy of zlib.lib for 32-bit and 64-bit builds of my app, and the app itself uses MFC in a dynamic DLL. Everything links just fine, and zlib is not in a DLL.
I'm trying to understand what exactly all of these are and how they relate to each other (and most importantly, how to install them).
From what I've read, LIBs are libraries linked during the compilation of my project and DLLs are libraries linked during the runtime of my project.
So for me to use a LIB, I have to have the actual .LIB file somewhere in my computer, go to Project -> Properties -> VC++ Directories and add the path to the file in the Library Directories, and after this I have to go to Linker -> Input -> Additional Dependencies add the .lib name in there, and finally I need to type #include in my code, right?
So, some questions:
When I finish and build the release of my program, will the .exe only run if the target platform has the .lib installed in their PC as well? If yes, what steps do I need to do to make sure the .lib goes with the .exe?
When I get the source of a open source project, if I add them (using Add Existing Item...) to my project, can I use them just by using #include as if the files were mine and it would be the same as having the .lib installed? Or do I need to install the .lib file and still use these source files?
I have a project using OpenGL and I linked to glew32.lib, but I don't have the lib or any new directory added in the VC++ Directories, so I think this means I must've installed the .lib in the system folder or somewhere where the Visual Studio won't ask for another directory, should I worry about this when releasing a project?
How the above questions relate to DLLs and is there any reason why should I use DLLs over LIBs or the other way around?
I'm starting to use more and more libraries and I noticed I just dragged, copied and included it everywhere so I could use them but never really understood how they "fit" in the project. Especially those open source libraries where they provide so many files and I don't really know what to do with them...
You don't need to have LIB files along with your EXE file for running in another computer, LIB files are static files and DLL files are dynamic. So when you compile all static codes will be included in your EXE file, but DLL files will be loaded and used dynamically in runtime, so you just need to have your DLL files with your EXE file. This way, your code will work and run properly in other computers.
Just adding another project is not enough, you need to compile them and generate LIB files out of them. Then you add the generated LIB file to your final project and include external projects in your final binary. If you are compiling multiple projects together in a solution, you'll need to set project build order in solution properties in VS.
No, that's OK. It seems you've put LIB files in right folder and you don't need to have LIB file with your EXE file to run it in other computers.
DLLs are dynamic libraries, so you need to have them with your application. Installers usually install EXE files with DLL files in the same folder, so your app will run properly, but no need to include LIB files at all.
Also you can include LIB files like this:
#pragma comment(lib, "glew32.lib")
So you don't need to do it in project settings, but assuming you have your LIB file in "Library Directories" path.
Using DLL files can be done in two ways:
One is linking your application to DLL file and having DLL file's function entry in your EXE file's import table:
like using
#include <windows.h>
then
GetWindowsDirectory(windir, MAX_PATH);
So you'll have GetWindowsDirectory API entry in your EXE file's Import Table.
Also you can do it dynamically:
hinstDLL = LoadLibrary("kernel32.dll");
if (hinstDLL != NULL)
{
func_GetWindir = (DLLPROC) GetProcAddress(hinstDLL, "GetWindowsDirectoryA");
...
There is not much difference, only difference is:
In first method, as it's in your EXE file's Import Table, if there was no kernel32.dll or there was no GetWindowsDirectory entry in kernel32.dll, your EXE will not run at all, it will show a critical error and will not run. But in dynamic way (second way), your app will run, but as soon as your code try to use GetWindowsDirectoryA API, it will fail. You will have 0x00 in func_GetWindir. If you attempt to call it, then program will crash.
Using netbeans 7.2 and the most recent version of MinGW (using installer) I can't use the libnoise library. I am properly including the header files, the auto completion confirms this, however the library is simply not working. There is a .lib file and a .dll. I have tried every possible combination of adding them under project > properties > Build > Linker as well as putting the .dll in the base project directory. Despite all this I am still getting undefined reference errors whenever I try and run the code. Does anyone know what to do?
I know that it is possible to link import library files (*.lib) with MinGW, but I still suggest to recompile libnoise.
With the current Makefile, this is not very easy and may break. Thus I've written a CMake script, which doesn't only work on Windows, but should work on all CMake supported platforms. In addition to this, I've cleaned up the directory structure. The code itself hasn't been touched and when you build a library it should essentially be the same as the current one.
libnoise on GitHub
After you've built your shared library, you'll have a libnoise.dll.a and libnoise.dll file. You then add libnoise.dll.a to the linking settings and put the DLL itself next to the binary, or in the working directory.
You have to link the lib file (= adding it to linker libraries) and put the dll to
<project root>/dist/<...>/
(where your exe is put to). There's no need to add the dll to linker too.
Can you please post the error message you get?
I have a DLL that I compiled from source (gdal). I have a simple C++ Win32 console project that has one source file, but I want to link against that DLL. Currently, when I try to run the project, it compiles correctly, but says that it cannot find the DLL. If I move the DLL to the same directory as the DLL, the exe will run. Is there a way to make my output EXE include the DLL so that I can just move one file to another system and run it without having to send the DLL with the exe.
How can I make this happen in VS2010?
Unless you had the original source code for the .dll, recompiled as a static library (.lib) and then statically linked to it, I don't believe there's a way to "include" the dynamically linked library inside your executable.
You need the DLL in the path, or in the current directory for your application to run. That is how it works with DLLs.
With static libraries, the linking embeds the library code into your application. If you cannot or do not want to have the DLL available, you could change your DLL to a static library.
Since you are compiling it from source you can just add the source files to your project and build it right into your executable.
You could create a Post-Build Event in the Visual Studio project that runs a script to copy the DLL to the path of the executable.
Then, when you deploy your application, an installer would be able to take care of the DLL management for you.
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.