I've worked with a couple of Visual C++ compilers (VC97, VC2005, VC2008) and I haven't really found a clearcut way of adding external libraries to my builds. I come from a Java background, and in Java libraries are everything!
I understand from compiling open-source projects on my Linux box that all the source code for the library seems to need to be included, with the exception of those .so files.
Also I've heard of the .lib static libraries and .dll dynamic libraries, but I'm still not entirely sure how to add them to a build and make them work. How does one go about this?
In I think you might be asking the mechanics of how to add a lib to a project/solution in the IDEs...
In 2003, 2005 and 2008 it is something similar to:
from the solution explorer - right click on the project select properties (typically last one) I usually select all configurations at the top... Linker Input
Additional dependencies go in there
I wish I could do a screen capture for this.
In VC6 it is different bear with me as this is all from memory
project settings or properties and then go to the linker tab and find where the libs can be added.
Please excuse the haphazard nature of this post. I think that is what you want though.
Libraries in C++ are also considered helpful, but the way you integrate them is different to Java because the compiler only has to see the interface of the library, which is usually declared in header files. In Java, the compiler will have to inspect the actual libraries because Java doesn't have this distinction between an externally visible header file and the generated object code providing the implementation.
What you normally do is build the libraries separately, once, and put the generated lib/dll files plus the header files into a place that projects requiring the library can access. A common idiom is to put the header files into
include, the static libraries into
lib and the dynamic libraries into
bin subdirectories for your compiled library.
The reason you have found that most C++ libraries are provided in source code form and not in precompiled form is that every C++ compiler has a certain freedom as to how to mangle symbol names etc and the resulting object code isn't portable across compilers, let alone operating systems. So shipping the compiled code doesn't make sense for a lot of applications. You'll occasionally find it with closed-source C++ libraries on Windows (C libraries are an entirely different matter), but then the vendor will have to provide a compiled version for each and every build type (Release, Debug, 32 bit, 64 bit etc) and target compiler (various versions of Visual Studio require different binaries, then there is Borland and a bunch of other compilers) and it quickly becomes a nightmare to support...
When you take a library and build it as a dynamic library on Windows (ie, a DLL), the compiler/linker will normally generate a static 'import' library for it (same name, just with a .lib extension). When you link your project against the dynamic library, you specify the .lib file as a library dependency. Linking your application against said import library allows the linker to record the dependency on the .dll file and also which symbols it should expect the library to provide.
Making them work - in the sense of your program finding them on Windows - usually requires that the .dll file is either in the same directory as the executable or accessible via the 'PATH' environment variable and its equivalent in Visual C++.