So I am writing a plugin that will be using some .dll .lib packages. I've successfully got the plugin's Build.cs to include the .lib but it wont compile. I get an external symbol not found error that just wont go away. I've placed the .dll at all the locations I can think of where the linker should pick it up to no avail (Binary folders in and out of the plugin, (Win64 and "ThirdParty")), Public and Private Folders in the plugin, project root, you name it.
Does anyone know how to link a .dll for use in a plugin? (fyi, I just want to expose part of the .dll to Blueprints or use them in C++ functions that get exposed to Blueprints).
How do you know that your Build.cs includes the .lib file?
Also, you can not include just every lib file, it has to be compiled with the correct compiler options or the linker will not like it (see here).
Adding DLLs is more complicated than adding libs, because you have to do it at runtime: https://wiki.unrealengine.com/Linking_Dlls
Related
Sorry if this has been asked before, but I can't seem to find an answer.
Let's say you have two projects within a solution. One is compiled to a dll, with an accompanying .lib for exports. You'd like to use and reference that module in your other project.
Can you somehow add a reference to the .lib stub within Solution Explorer? Or is that just for static libs? Thank you for your help.
For implicit linking to a DLL, you can set up linking to the .lib stub exactly as you would if it was a full static library. For example, add "mylibstub.lib" to Configuration Properties/Linker/Input/Additional Dependencies and add the directory where it is built to Configuration Properties/Linker/General/Additional Library Directories as a path relative to the project directory.
Just doing the above should get you building. You are then going to need to get the DLL somewhere where it is going to be found when you run your executable from Visual Studio (assuming that the other project in the solution is an executable). One way to do this is to add the directory where the DLL is built to the path environment variable via Configuration Properties/Debug/Environment; see here. Another way would be copying it in a post-build step.
I have a project that works great.
I created a new and independent .dll project that contains the origin project with some exported functions (copied the origin .h and .cpp files to the new project). I copied from the origin project all the lib dependencies and paths to those libs and additional include files. its the same setup.
The new program compiles but the problem is that when I try to run the code, I get that error msg:
The program can't start because xxx.dll is missing from your computer. Try reinstalling the program to fix this problem.
that xxx.lib is on the Additional dependencies list and its not the first one:
Additional Dependencies: aaa.lib; bbb.lib; ccc.lib; xxx.lib, zzz.lib
I guess that VS found the first three .lib otherwise I would get some error message.. so why can't it find xxx.lib? all the .lib files in the same folder..
thanks.
You appear to be misreading the error message. It says:
The program can't start because xxx.dll is missing from your computer. Try reinstalling the program to fix this problem.
Note that it says xxx.dll is missing, not xxx.lib!
On Windows, a LIB file is often used as an aid to the linker when using a DLL. The LIB contains import stubs for functions provided by the DLL. You need the LIB file when you build the binary; you don't need the LIB file on the machine to run the resulting binary. However, you do need the DLL!
The reason that this might be confusing is that, if you are going to statically link an object file, you only need the LIB. It contains all of the code, and there is no DLL required. But this is not the strategy you are using. The linker is using the xxx.lib file to arrange for the EXE to be dynamically linked to xxx.dll. Thus, the EXE requires the DLL to be present in order for it to run.
Copy xxx.dll into the same folder as your EXE, and then launch the application again. This has nothing to do with your compiler/linker/build settings.
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.
I followed the MSDN walkthrough on creating and using a DLL in Visual C++ Studio, but it requires the user to add the DLL project to the same solution as the project they're working on.
Is there a simple way to include a DLL? Ideally, I'd like to just distribute my .dll (and the .lib, I suppose) to my friends so they can use it in their own projects.
I realize there are other walkthroughs out there (some of them on SO), but they all require editing the PATH environment variable, etc. Is that really the simplest way?
At a minimum, you need to do the following:
Include the .lib file in the project
Tell the linker where you put the .lib file (library search path)
Make the .dll file available at runtime (easiest is to put it in the same directory as the .exe)
To distribute the compiled .dll to your friends, you will need to include:
the .h file(s) for the compiler
the .lib file for the linker
the .dll file for runtime
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