I've noticed that most of the problems in this forum are from a lack of understanding in the overall compilation and execution of your programs. I think the lecturers should seriously devote more time to explaining this since you are all getting very frustrated over something that is essentially a very simple concept but seems to have been glossed over.
When you create a project, you organise your code into a series of files. Some are source files (cpp), some are header files (h). Each source file gets compiled independently of all others and thus, if you have references to classes/functions/etc that are in other source files, you need to make the compiler aware of these by including their declarations that are in the header files.
Once each source has been compiled, it's intemediate code is packaged into object files. The MinGW compiler names these *.o files, the MS compiler names these *.obj files. Object files are not compatible between compilers.
You can then use a linker to create the final output. There are three types of output that you can generate: stand-alone executables, static library files and dynamic (or shared) library files.
A static library is a package of intermediate code. You can imagine it as a collection of precompiled source files all put into one file instead of many object files. They are useful because you don't need to compile them again and again if you want to reuse the same code in multiple projects. You only have to link the code into your current project. MinGW linker creates *.a files while the MS and Borland compilers create *.lib files. Once again, these files are not compatible between linkers.
An executable is the one you're most familiar with. It is created by the linker by taking all the intermediate code in the object files you've compiled, looking for relevant code in any static libraries you've mentioned and then combining them together and turning them into machine code that can run on the operating system.
A dynamic/shared library is also executable code but it cannot run on it's own. You execute it by loading it via a stand-alone executable. The two files then run side-by-side together till either the stand-alone exits, or it unloads the dynamic/shared library. This is very useful because, if you wish to change a portion of code in a dynamic/shared library, you only need to recompile that library and ship it to your customers, you don't need to recompile the entire project. In addition, if you put reusable code in a dynamic/shared library, you don't need to recompile or link it to every project that needs it. Remember that although a static library is not compiled every time you use it, it still needs to be linked into your executable. With a dynamic/shared library, this step is not necessary since the linking step happens when you need it at runtime. The disadvantage is that loading/unloading a dynamic/shared library is relatively slow.
I hope this clears the definitions up, now to your problems.
When you have 3rd party software (eg, Qt or Ezust) that you can reuse and link to your own code, it's usual for the supplier to give you one of two kinds of packages:
1) A set of header files and a static library
2) A set of header files, a static library and a dynamic/shared library. In this case, the static library is very small and only contains predefined code to help you load and unload the dynamic/shared library automatically, otherwise you'd have to code for it manually.
[you'll rarely get the source code files as well unless it's from an open source project]
In either case, you'll very likely not store these files in the same directory as your own project so you need to tell the compiler where your files are. All compilers will have their own way of dealing with this. Qt tries to standardise this by using project files. qmake then creates the necessary Makefiles that are specific to the compiler you're using (see QTDIR/mkspecs for a list of supported compilers).
In Qt, you would specify the location of the header files with the INCLUDEPATH variable, then you use it in your source code by adding a #include <> precompiler directive.
Since the 3rd party code is usually already compiled and packaged into a static library, you need to tell the linker where to find the library and what it's name is otherwise you're going to get "undefined reference" type of errors. You need to specify two things, the path where the library is found, and then also the specific static library to link to. In Qt you put both of these bits of information into the LIBS variable but you mention the library path with the -L switch and the libary name itself with the -l switch. You only need to mention a path once. If you need to link more than one static library but they are in the same path, you would only mention the path once.
e.g
LIBS += -L/path/to/libraries -lstaticlib1 -lstaticlib2 -lstaticlib3
Note: Qt tries to help you here. If it knows what compiler you are using, and you forget the file's extension, it will append this to the search list. eg if I'm using ld.exe (MinGW's linker), and I mention -lstaticlib1, then Qt will change this to -lstaticlib1.a. Don't count on this though, rather name the library file completely. See the qmake documentation for more information about this.
If you follow these steps, you should be able to compile and link properly.
The last thing you need to do though is take care of the dynamic/shared libraries. When you compile a program, the entry point function is main(). This is not actually where the execution begins. All compilers add extra management code. This is responsible for setting up the program and initialising the static variables etc. Each compiler not only adds the absolute minimum but some extra helpful functions as well (eg memory management). These are usually packaged into what's commonly called a runtime library. You can specify that this library is statically linked into your executable but by default, it's supplied as a dynamic/shared library. For MinGW, this code is inside the mingwm10.dll file, for MS, this is in the msvcrt70.dll (or something to that effect). These libraries are required for every project you create.
When you have compiled your executable, you need to make sure that the dynamic/shared libraries are visible as well. The common thing, if you create the libraries yourself, is to include them in the same directory that your executable is in. If not, they need to be in one of the search paths so that the operating system can find them. In Windows, this would be the PATH environmental variable, in Linux, this would be the LD_LIBRARY_PATH variable.
The runtime library should already be in the search path. The compiler should have added it upon installation. If you're using MinGW, you should see a directory ending with mingw/lib in the PATH somewhere. Also, most of the Qt dynamic/shared libaries are in the qt/lib directory (or QTLIB/lib if you set up the variable yourself).
For most of your programs, you'll need at least your program executable and the runtime library. For Qt programs, you'll also need:
QtCore4 - the core classes that handle the basic Qt types and the QObject system
QtGui4 - All the basic GUI classes
(Note: There should be two versions of each dynamic/shared library, one for release builds and one for debug builds. The debug versions have 'd' after the version number)
If you want to install your program on another computer, you'll need to package all these files together and transfer them all to the new machine.
Hopefully, you'll find this useful and not too long-winded and that it helps clear up all your problems.
