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.
Related
I am working on a project that involves making a dynamic link library, so I want to test it in a console app in Visual Studio.
The DLL is also made in Visual Studio, it doesn't have much, just a few functions in it. I'm not sure if I'm just supposed to include the librarys header in the include directories panel in Properties, or do something else
A lot of people say I'm supposed to add its corresponding .lib file in the Library or Reference directory, but I'm not sure that VS generates a .lib file alongside the DLL. I'm using VS 2015.
I don't have VS in front of me this very moment, but these should be the general steps to set it up:
Properties->Linker->Input: your.lib
Properties->Linker->Additional Library Directories: ../your/bin
Properties->General->Compiler->Additional Include Directories: ../your/include
To build your app, the DLL's API headers must be in the include for the compile-time, it's LIB files in the bin for the link-time. Once you have your app EXE, all you need is the DLL to be in the same folder as your EXE when it executes.
You might also want to add the dll project and the app project into a common solution in VS and add (right click) Project Dependency from the app to the dll. This ensures correct order of building, assuming you are going to build the dll at all.
You can also do what I did.
You can create a Libs directory inside of your Solution directory.
You can then place your .DLL files inside of the Libs directory or some sub-directory inside of Libs
In my case, I added the entire SFML-2.3.2 directory in there, which included the source-code, .lib files, and .dll files.
I did link up what I could in the project properties, but I used Visual Studio's macros to fill in the path name to the Solution directory. Just in case I wanted to put this in version control and work on it from multiple machines.
Then I opened up the Project's Property Page.
Within the property page, I went to Build Events -> Post-Build Event -> Command Line
Within the Command Line, you can add a copy command that will copy any needed files into the same directory as the executable that will need them.
In my case I used: copy "$(SolutionDir)Libs\SFML-2.3.2\bin\*" "$(TargetDir)"
I could have written multiple commands to copy just the individual files that I needed, but I had spent a good three hours trying to get SFML to work without actually installing it.
I am trying to learn more about Multiplayer Modifications so i've downloaded the source code of San Andreas Multiplayer.
My problem is that the client project creates a .dll and a .lib files. I've searched on many sites how to implement them into a new project but i just did not find a clear answer.
So i am creating a new Visual C++ project where i need to implement the libraries resulted from SAMP Client compilation. Any help would be great :).
If you want you can join me in this project.
I don't know how SAMP dlls are but in general, this is how it works:
Linker need *.lib files. So you should copy lib files to your default lib directories or create a new directory under libraries of your project and copy them in it.
If the project you want to link have include files too, do what you did for lib files for include files too. Copy them to include directory.
Put DLLs in a directory that your application can reach. This can be your Debug folder or even it can be Windows or System32 directory. Choose where to put them on your own (it depends on many parameters. Pick one that fits you).
This link tells you how to put them in project directories.
That's it. You can call functions of the project you want to use. Tell me if you got problem.
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 currently have a console project which creates an .exe file; I want it to also create a .lib file so other projects, compiled as DLLs, would be able to call functions from the original project.
I know it is possible, but I couldn't find how to do that. How do I tell the linker to also link a .lib?
Posting this just as a reference I know the original post was posted long time ago but this still applies to anyone who needs a solution to this problem.
Go to the project you want to make a .lib file for and follow these steps:
Right click on the project.
Select Properties.
Select Build Events.
Select Pre-Link Event .
Finally in the Command Line paste this:
#ECHO ON
#ECHO "$(VC_ExecutablePath_x86)\lib.exe" /out:"$(OutDir)$(ProjectName).lib" "$(IntermediateOutputPath)*.obj"
"$(VC_ExecutablePath_x86)\lib.exe" /out:"$(OutDir)$(ProjectName).lib" "$(IntermediateOutputPath)*.obj"
This will call the lib tool to generate the lib file out of the generated object files.
It's not possible in general - static libraries and executables are completely different kinds of animal. The way to handle this situation is to create two projects - one for the library, which contains all the functionality. and one for the executable, which is a thin wrapper that simply calls functions in the library.
If any symbol in a Application (.exe) project is exported (e.g. with __declspec(dllexport) ), both the .exe and the .lib files will be generated
See:
Why does my Visual C++ .exe project build create .lib and .exp files?
It is amazing how many contributors arrogantly insists on an answer that is wrong, when they simply don't know the answer.
To generate a .lib associated with your .exe place the following line in Pre-Link Event:
"$(VC_ExecutablePath_x86)\lib.exe" /out:"$(OutDir)$(ProjectName).lib" "$(IntermediateOutputPath)*.obj"
You don't "also link a lib", you create a static library project. The latter doesn't call the linker at all -- instead it compiles all your files with cl /c and combines the resulting .objs into a lib using lib.exe.
I understand that I need to use LoadLibrary(). But what other steps do I need to take in order to use a third-party DLL file?
I simply jumped into C++ and this is the only part that I do not get (as a Java programmer). I am just looking into how I can use a Qt Library and tesseract-ocr, yet the process makes no sense to me and is so difficult to google.
How do I tell the compiler of the functions that I am using? Should there be an include file from the third-party vendor?
As everyone else says, LoadLibrary is the hard way to do it, and is hardly ever necessary.
The DLL should have come with a .lib file for linking, and one or more header files to #include into your sources. The header files will define the classes and function prototypes that you can use from the DLL. You will need this even if you use LoadLibrary.
To link with the library, you might have to add the .lib file to the project configuration under Linker/Input/Additional Dependencies.
To incorporate third-party DLLs into my VS 2008 C++ project I did the following (you should be able to translate into 2010, 2012 etc.)...
I put the header files in my solution with my other header files, made changes to my code to call the DLLs' functions (otherwise why would we do all this?). :^) Then I changed the build to link the LIB code into my EXE, to copy the DLLs into place, and to clean them up when I did a 'clean' - I explain these changes below.
Suppose you have 2 third-party DLLs, A.DLL and B.DLL, and you have a stub LIB file for each (A.LIB and B.LIB) and header files (A.H and B.H).
Create a "lib" directory under your solution directory, e.g. using Windows Explorer.
Copy your third-party .LIB and .DLL files into this directory
(You'll have to make the next set of changes once for each source build target that you use (Debug, Release).)
Make your EXE dependent on the LIB files
Go to Configuration Properties -> Linker -> Input -> Additional Dependencies, and list your .LIB files there one at a time, separated by spaces: A.LIB B.LIB
Go to Configuration Properties -> General -> Additional Library Directories, and add your "lib" directory to any you have there already. Entries are separated by semicolons. For example, if you already had $(SolutionDir)fodder there, you change it to $(SolutionDir)fodder;$(SolutionDir)lib to add "lib".
Force the DLLs to get copied to the output directory
Go to Configuration Properties -> Build Events -> Post-Build Event
Put the following in for Command Line (for the switch meanings, see "XCOPY /?" in a DOS window):
XCOPY "$(SolutionDir)"\lib\*.DLL "$(TargetDir)" /D /K /Y
You can put something like this for Description:
Copy DLLs to Target Directory
Excluded From Build should be No.
Click OK.
Tell VS to clean up the DLLs when it cleans up an output folder:
Go to Configuration Properties -> General -> Extensions to Delete on Clean, and click on "..."; add *.dll to the end of the list and click OK.
These are two ways of using a DLL file in Windows:
There is a stub library (.lib) with associated header files. When you link your executable with the lib-file it will automatically load the DLL file when starting the program.
Loading the DLL manually. This is typically what you want to do if you are developing a plugin system where there are many DLL files implementing a common interface. Check out the documentation for LoadLibrary and GetProcAddress for more information on this.
For Qt I would suspect there are headers and a static library available that you can include and link in your project.
In order to use Qt with dynamic linking you have to specify the lib files (usually qtmaind.lib, QtCored4.lib and QtGuid4.lib for the "Debug" configration) in
Properties » Linker » Input » Additional Dependencies.
You also have to specify the path where the libs are, namely in
Properties » Linker » General » Additional Library Directories.
And you need to make the corresponding .dlls are accessible at runtime, by either storing them in the same folder as your .exe or in a folder that is on your path.
You only need to use LoadLibrary if you want to late bind and only resolve the imported functions at runtime. The easiest way to use a third party dll is to link against a .lib.
In reply to your edit:
Yes, the third party API should consist of a dll and/or a lib that contain the implementation and header files that declares the required types. You need to know the type definitions whichever method you use - for LoadLibrary you'll need to define function pointers, so you could just as easily write your own header file instead. Basically, you only need to use LoadLibrary if you want late binding. One valid reason for this would be if you aren't sure if the dll will be available on the target PC.
I'f you're suppsed to be able to use it, then 3rd-party library should have a *.lib file as well as a *.dll file. You simply need to add the *.lib to the list of input file in your project's 'Linker' options.
This *.lib file isn't necessarily a 'static' library (which contains code): instead a *.lib can be just a file that links your executable to the DLL.