To use C++ libraries we need to copy .dll files from bin folder, we are either instructed to paste them in the project directory OR in C:/windows32/.
Does it matter where we paste .dll files besides the scope of accessibility ?
It’s a very bad idea to write files to the system directory if you have an alternative. (And if you did need to, you’d check the environment variables instead of hardcoding.)
At best, no other program will install a library by the same name, so you’ll have a bit of extra junk in your system directory. It can’t be removed when you uninstall the program, because it was never registered and you have no way of knowing if some other application needs it.
At worst, two different programs will install different versions of FOO.DLL and one of them will break. This is affectionately known as “DLL Hell,” and the solution was for everyone to put their DLLs in the project directory. (Or sometimes, the vendor’s Common Files.)
Related
I understand that .lib is static library linking and .dll is dynamic. This means that when .exe is produced, .lib does not need to be around for .exe to work. However, .dll need to be put in the correct relative path for .exe to reference and run.
My question is for .lib. When uploading the source code to Github, do I include .lib file in the project folder as well? What is the best practice in doing so?
Most of the tutorial that shows how to install library makes us link .lib file to its original folder and move .dll file into the working project folder. So should I move .lib file into my project folder as well? If I don't do that, it means the person that download my source code will have to go find the corresponding .lib file to link and compile right?
My own "IMHO answer" would be: "GitHub is concerned with source code." Therefore, I would not suggest including a binary .lib file there. And, I probably also would not put a binary .dll file there, either.
To clarify the difference between the two files ...
A .lib file is a library of object-code, resulting from previous compiles, that can now be referenced by the linker. The linker will choose whatever it needs, then copy these items out of the library into whatever it may be building at the time.
A .dll is a dynamic library ... "dynamic" in the sense that applications (and, other DLLs ...) can load it and unload it at runtime. (The Windows program-launcher also automatically loads any DLLs that are directly or indirectly referenced by anything it is launching.)
.dll's are "all or nothing." You load them in their entirety, at runtime. .lib's, by contrast, are true libraries, which are used only by the linker.
=== Edit: And the next Answer, IMHO, "nailed it."
Git repos are about code, and you should not have binaries in your git repos.
However, github has a feature called releases which allows you to upload binary assets alongside your tagged source releases.
You can add your compiled libraries there.
Your question is really about dependency management. Irrelevant of .lib or .dll, these are just different sorts of dependencies. Your question is if someone clones my repository, how can they build it?
The answer is you need a build script, makefile, rakefile, jake file, etc... something that the user can run to do the build. For instances this could be a README which says: "go download the files you need from website X". Alternatively you can do as you suggested an put the necessary dependencies within your repository. Legally this isn't always permitted as it is considered "redistribution". The best approach is to use some sort of dependency management. Depending on the language you are using there are different dependency management solutions. I would recommend only using libraries (.dll, .lib, .tar, .*) from public dependency repositories.
In Java, the recommended approach is using something called maven. Ruby has gems, node.js has npm packages. This is nothing more than a file with a list of dependencies, and a tool which knows how to retrieve them. To build my libraries it is as simple as running
npm install && node make.js which says run the nodejs package manager (dependency manager) to download all the necessary files, and then run the build script.
For C++ it could be something like make install && make which would require a makefile you configure to say these are the things which need to happen before the project can be built.
Personally C++ has poor dependency management, but that may turn out some negative responses, I'll just say dependency management in C/C++ isn't my favorite and for mostly internal software or small use I would still with committing the lib with your code. If there is a public repository which contains your lib files you could always generate a makefile/Cmake to curl or wget as part of the build process before you call gcc compiler.
I'm a beginner with building software using C++. In my project I link to DLLs and I keep them stored in the root folder. I do this because I want the project to be portable from one machine to another, and I also want the release builds to have dependence from installing things into system32 and what not.
The problem is all the DLLs in the root folder is messy, so I want to organize them into subfolders. But I can't do that because putting the DLL in a root subfolder instead of the root, you get errors. I think because the DLL is copied to the output at the wrong location, not where the exe is, but in a subfolder, just like the source structure. Am I right about that?
What is a solution that will allow me to have the project be still be copy-pastable/portable between machines?
Windows searches for DLLs in predefined locations (see Dynamic-Link Library Search Order). Subdirectories of the directory where the application resides are not part of the search order.
To implement your requirement, you will need to explicitly add the directories to the searched locations. This process consists of two steps:
Call AddDllDirectory for each directory you want searched, in addition to the default search locations on application startup.
By default, DLL imports are resolved prior to starting a process' primary thread. To allow your application to change the DLL search path, import resolution needs to be postponed. The easiest way to do this is by using the /DELAYLOAD (Delay Load Import) linker option (see Linker Support for Delay-Loaded DLLs for additional information).
While it is possible, to segregate DLLs into subdirectories, it is best to keep them all alongside the executable image.
If you put the DLLs into subfolders instead of keeping them in the same directory as the executable, you would either have to modify PATH environment variable in Windows to point to every subfolder, or use the DLLs in LoadLibrary+GetProcAddress way instead of linking them to the executable via import libs.
I made a program with Microsoft Visual Studio 2010. It uses additional libraries (Allegro), and it runs perfectly from MSVC, but I can't run it from it's directory. (...\"project name"\Debug\"project name".exe) It writes that it can't find some kind of .dll files.
That's not good, because I want to make it work for everyone! What to do to make it work?
I know that I have to put the necesarry .dll files, but I don't know where?
When an executable is started, Windows searches the current directory, the PATH and then some other places. The exact description can be found here
You need to make sure either the PATH includes the library you need, or place it in the same directory (or in some other automatically searced directory, but that's typically not a good solution).
I read this guide that walks you through the steps necessary to create a "visual" application with Cairo and Visual C++. The guide suggests you download certain dll files and store them in the directory in which your executable is created (debug).
Here is the list of the files Nil is referring to in his tutorial:
cairo Binaries (yes you need the binaries package too, as the Dev one doesn't contain the DLL) -> libcairo-2.dll
zlib Binaries -> zlib1.dll
libpng Binaries -> libpng12-0.dll
Freetype Binaries -> freetype6.dll
FontConfig Binaries -> libfontconfig-1.dll
expat Binaries -> libexpat-1.dll
As you can see, it's quite a lot of files. I've been wondering if this the "correct" way of doing this? Is there an alternative way that is considered "best-practice" in this case?
There's nothing wrong with this approach, and it's probably the quickest way to get your application up and running. Your application needs these libraries, so putting them in the same folder allows it to find them.
There are of course always alternatives!
Static linking
To avoid having a bunch of dlls that have to exist with your application, you could use static linking. You link the .lib files at link-time rather than linking to the .dll files at run-time. Makes your .exe larger, but means you may be able to distribute a single file.
Placing Dlls in a different folder
The dlls do not have to be in the same folder as the .exe, though that normally makes the most sense. Windows will search several folders when looking for a .dll at run-time, so you could put the dlls in the current directory, a system directory (definitely not recommended), or another directory in your PATH environment variable. Actually none of those locations are recommended! Putting them in the same folder as the .exe is the safest, because generally you have control of that folder.
The specific rules for how Windows searches for a .dll are outlined here: http://msdn.microsoft.com/en-ca/library/windows/desktop/ms682586(v=vs.85).aspx
Custom Build Step
I don't like manually putting files in my debug or release folders. I like to think of the debug folder as something I can blow away and rebuild at any time, and I like to have a one-step build process that puts everything where it needs to be so I can easily build on any machine. So I will usually create a custom build step that copies the required .dlls from a "source" folder (in source control) into my output folder.
What I am trying to do is exactly like the instructions on this website:
http://www.cprogramming.com/tutorial/sdl/setup.html
The only problem is that I didn't download the version of Code Blocks that comes with the mingw32 compiler. I got the latest release from http://www.equation.com/servlet/equation.cmd?fa=fortran and installed it in 'C:\gcc'. So, the folders that it is asking me to move files into don't exist.
The article asked me to download this file:
SDL-devel-1.2.15-mingw32.tar
Then in that file move the 'include\SDL' folder into the 'C:\Program Files\CodeBlocks\include'. (I don't have a CodeBlocks\include folder)
It then asked me to move the 'SDL.dll' to 'C:\Windows' which I was able to do.
Finally it wanted me to copy the contents of the 'lib' folder into the 'CodeBlocks\lib' folder. (Another folder I don't have because I installed my compiler separately from the Code Blocks install)
Since I installed my compiler at 'C:\gcc' I tried to add the files into the 'C:\gcc\include' and 'C:\gcc\lib' files, but that didn't work.
I am not very familiar with the process of using 3rd party libraries. I usually use Java where you can just stick the .jar file in with your code. Do I need the .dll, include, and lib files. Where do I actually need to put them? I would also appreciate knowing why as well?