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.
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 implemented the SFML library nightly build to my Visual Studio 2013, because the original one is not compatibile with this VS version. I done everything what is needed (added directory to include folder in both Debug and Release, added directory to .dll files), but it can't find the files in program. What else should be done to make this library work? Or should i consider changing Visual Studio to 2010?
You haven't given really to much information so I am just really guessing as to what the problem is.
added directory to .dll files
But that sounds like your problem right there. You don't add the directory that the .dll files are in to your project. The only directories you need to add to the project are the include directory and the library directory.
But anyways I am assuming you are using dynamic linking since otherwise you wouldn't be dealing with .dlls. Now different IDE's require that you place the .dlls in different spots but since you are dealing with VS2013 you need to copy whatever .dlls that you are using into the same folder where your program's compiled executable is (The .exe file).
Another option is to link statically instead of dynamically which I generally prefer to do on small projects but it is really up to the developer which he prefers.
When you link statically you don't need to include any .dlls. What you will need to do is recompile SFML's sources and make sure to build the library so it produces the static library files (They should be named something like sfml-graphics-s-d.lib for debug and sfml-graphics-s-d.lib for release).
Add that library directory which contains the static library files to your project and then link to them .lib files in VS's input window (Remember that -d is for the debug build).
Next you will need to add SFML_STATIC to your preprocessor options on both the release and debug build.
After that you are good to go and don't need to include the .dll files with your project. And again whether you choose to link dynamically or statically is really up to you and the project you are working on but for small projects I would suggest linking statically.
I'm trying to write an application that wraps SVN. I've downloaded the binaries for it, and all I've found are DLLs.
Is there somewhere where I can find the .lib files? Or do I need to use LoadLibrary and find each method manually? Or do I just need to include the SVN source code, which would be a pain to maintain.
EDIT:
I have found a download that has all the .libs and include files after following this question, anyone else trying to find an answer should look here:
For anyone else who may be looking for the same thing, there is a download here that has everything you want!
Are there Windows API binaries for Subversion or do I have to build SVN to call the API from Windows C++?
I don't think that what you want is readily available as very few people use that. You are searching for a developer build for svn.
Your best chances are to download the source code for svn and compile it yourself. That way the lib files will be generated and you will be able to link against them.
EDIT : Another option you have is to use another layer of wrapper around SVN and use something like rapidSVN API. This will expose most common svn features and you don't have to handle the svn source code.
EDIT2 : I think that they moved to github
https://github.com/RapidSVN/RapidSVN
DLL's are libs, but they are dynamic libs, loaded and executed during run time. Lib files, however, are libraries that have been loaded into the compiler and used to compile the binaries. In your case, there wouldn't be lib files because the .exe binaries already have the libs built into them. Where-as, you do get the DLL's because they aren't built into the binaries, but instead are loaded somewhere inside the binary during execution.
There is no reason to include the .lib's in a binary download since the binaries don't need them anymore to function. The only reason you would need .lib files is if you had the rest of the source code in order to build your own .exe again.
I am creating an application by using opencv2.3 IN VC++2010 express addition. The build is successful but while compiling it says that 'opencv_highgui230.dll was not found.Reinstalling the application may fix the problem.' Though I have added all the necessary include and lib files.
It's likely that this DLL can be found in bin or similarly named directory under where you installed the OpenCV library. For Windows binary distributions of various libraries, the DLL is usually included.
For your program to load it, it either has to be in the same directory as the executable, in your system directory, usually C:\Windows\system32\, or I think that it is possible to specify the location programmatically, in your code. This MSDN article can tell you more.
Quick and, more likely then not, correct solution would be to copy the DLL into your executable's directory.
Because your application relies upon the library, you have to build the library first before you build your application. The error message is telling you that it can't find the binary file corresponding to your library, opencv_highgui230.dll, not one of the code files.
You can either configure Visual Studio to automatically build the projects in the correct order by setting up the appropriate project dependencies, or you can do it manually.