Compiling and linking against Gecode
Including header files
Deciding which header files must be included when using Gecode is quite straightforward. There are the following header files for inclusion:
- gecode/support.hh must always included (support.hh header is included from kernel.hh)
- gecode/kernel.hh must always be included (the header files below also always include kernel.hh).
- gecode/search.hh must be included, if search engines are used (see for example Search engines).
- gecode/int.hh must be included, if any integer functionality is used (see for example Using finite domain integers and Programming integer actors).
- gecode/set.hh must be included, if any finite set functionality is used (see for example Using finite integer sets and Programming set actors).
- gecode/minimodel.hh must be included, if direct modelling support is used (see for example Direct modeling support).
- gecode/graph.hh must be included, if graph constraints are used (see for example Graph constraints).
- gecode/scheduling.hh must be included, if scheduling constraints are used (see for example Scheduling constraints and branchers).
- gecode/driver.hh must be included, if the script commandline driver is used (see for example Script commandline driver).
Other functionality is available through a set of header files. For example to access the implementation of particular propagators, a particular header file must be included. The header file to be included is always mentioned in the documentation of the class or function.
Linking libraries
Setting the exact name for a library on a particular platform aside, inclusion of header files basically coincides with against which library must be linked. That is:
- If gecode/support.hh is included, linking againg the support library is required.
- If gecode/kernel.hh is included, linking against the kernel library is required.
- If gecode/search.hh is included, linking against the search library is required.
- If gecode/int.hh is included, linking against the integer library is required.
- If gecode/set.hh is included, linking against the set library is required.
- If gecode/minimodel.hh is included, linking against the minimodel library is required.
- If gecode/graph.hh is included, linking against the graph library is required.
- If gecode/scheduling.hh is included, linking against the scheduling library is required.
- If gecode/driver.hh is included, linking against the driver library is required.
The functionality in Range and value iterators requires no library for linking. Reusing integer or set propagators of course require the integer or set library.
If there is a difference between library and DLL (such as on Windows) linking must be done against the appropriate library and the corresponding DLL must be available for execution (such as in the PATH environment variable).
The libraries might contain code that is executed at link time. If you create static libraries, this code will not be linked into your executable as it is not directly referenced. You will have to tell your linker to include all symbols from the library (e.g. using -Wl,--whole-archive on Linux). Please refer to your linker documentation.
Library names
Windows with Visual Studio
Gecode uses a technique called auto-linking with Visual Studio: by including Gecode header files, the compiler/linker knows which library and DLL must be linked against. Hence, it is sufficient to just provide information to the compiler where the libraries reside. When using the compiler cl for linking and assuming that the libraries reside in the directory dir, you should add at the end of the commandline: /link /LIBPATH:dir
The library and DLL names encode the Gecode version, the platform (x86, x64, or ia64), and whether Gecode has been built as release (optimized) or debug. That has the advantage that a single set of header files can be shared among different platforms and builds and the appropriate libraries and DLLs are selected automatically.
Unix (Linux, MacOS X)
Depending on whether Gecode was compiled as a static or as a dynamic library, different filename suffixes are used on different Unix platforms. All library names follow the following scheme:
- Support library: libgecodesupport.<EXT>
- Kernel library: libgecodekernel.<EXT>
- Search library: libgecodesearch.<EXT>
- Integer library: libgecodeint.<EXT>
- Set library: libgecodeset.<EXT>
- Minimodel library: libgecodeminimodel.<EXT>
- Graph library: libgecodegraph.<EXT>
- Scheduling library: libgecodescheduling.<EXT>
- Driver library: libgecodedriver.<EXT>
where <EXT> depends on the library type and platform:
- libgecode[...].a for static libaries on all Unix flavors
- libgecode[...].so for shared libraries on Linux
- libgecode[...].dylib for shared libraries on MacOS X
You can use for example
gcc -L$GPREFIX/lib -lgecodekernel
to link the kernel library, if the libraries are found in $GPREFIX/lib
.
Using Gecode with Visual Studios Integrated Development Environment
The following steps have to be taken when your solution uses Gecode (all of which can be configured in the properties dialog of your solution):
- Configuration Properties, C++, General: set the "Additional Include Directories" to include the directory that contain the headers (that is, to the directory that has the single directory "gecode"). When using the pre-built MSI packages, this is "<Program Files>/Gecode".
- Configuration Properties, Linker, General: set the "Additional Library Directories" to include the directory containing the libraries. When using the pre-built MSI packages, this is "<Program Files>/Gecode/lib".
- You must use dynamic linking against a multithreaded library (that is, either /MD or /MDd.
- Depending on whether /MD or /MDd is used, release or debug libraries and DLLs will be used automatically.