dlib C++ Library - How to compile

The Library

- Algorithms
- API Wrappers
- Compression
- Containers
- Imaging
- Metaprogramming
- Miscellaneous
- Network
- Parsing

Help/Info

- Examples
  - Base64_Encoder
  - Bayesian_Network
  - Bayesian_Network_From_Disk
  - Bayesian_Network_GUI
  - Cmd_Line_Parser
  - Compress_Stream
  - Directory_Navigation
  - GUI
  - HTTP_Server
  - Image
  - Kernel_Centroid
  - Kernel_K-Means_Clustering
  - Kernel_RLS_Filtering
  - Kernel_RLS_Regression
  - Logger
  - Logger_Advanced
  - Matrix
  - Member_Function_Pointer
  - Multithreaded_Object
  - Neural_Network
  - Pipe
  - Queue
  - Rank_Features
  - Relevance_Vector_Classification
  - Relevance_Vector_Regression
  - Sockets
  - Sockets_2
  - Sockstreambuf
  - Std_C++_Allocator
  - Support_Vector_Machine
  - Threaded_Object
  - Threads
  - Thread_Function
  - Thread_Pool
  - Timer
  - XML_Parser
- Home
- How to compile
- Index
- Introduction
- License

Current Release

- Change Log
- Release Notes
- Version: 17.12

Last Modified: Nov 10, 2008

# How to compile

To use this library all you have to do is extract the library somewhere, make sure the folder containing the dlib folder is in your include path, and finally add dlib/all/source.cpp to your project.

An example makefile that uses this library can be found here: dlib/test/makefile. It is the makefile used to build the regression test suite for this library. There is also a CMake makefile that builds the regression test suite at dlib/test/CMakeLists.txt and another CMake makefile that builds all the example programs at examples/CMakeLists.txt

I try to make sure everything compiles fine under Visual Studio .NET 2003 (and above) and gcc. The compilers that will give you trouble are listed at the bottom of the page.

Again, note that you should not add the dlib folder itself to your compiler's include path. Doing so will cause the build to fail because of name collisions (such as dlib/string.h and string.h from the standard library). Instead you should add the folder that contains the dlib folder to your include search path and then use include statements of the form `#include <dlib/queue.h>`. This will ensure that everything builds correctly.

# Preprocessor Directives

There are a few preprocessor directives you can supply during the build process to cause the library to build in various optional ways. Most people will probably not want to mess with these at all and will just use the library in its default build. But they are listed here in the event that you need to use them.

### #define DLIB_ISO_CPP_ONLY

This is a #define directive that you can set to cause the library to exclude all non ISO C++ code (The things in the API wrappers section and any objects that depend on those wrappers). This is useful if you are trying to build on a system that isn't fully supported by the library or if you just decide you don't want any of that stuff compiled into your program for your own reasons.

### #define DLIB_NO_GUI_SUPPORT

This is just like the DLIB_ISO_CPP_ONLY option except that it excludes only the GUI part of the library. An example of when you might want to use this would be if you don't need GUI support and you are building on a UNIX platform that doesn't have the X11 headers installed.

### #define NO_MAKEFILE

This preprocessor directive causes the dlib headers to pull in all the code that would normally be built in dlib/all/source.cpp. Thus if you #define NO_MAKEFILE you won't have to add dlib/all/source.cpp to your project. The only time this is useful is when your project consists of a single translation unit (i.e. a single cpp file). In this instance NO_MAKEFILE allows you to easily build your project on the command line by saying something like `g++ -DNO_MAKEFILE project.cpp`. But again, this is only for single cpp file projects. If you use NO_MAKEFILE with projects that contain more than one cpp file you will get linker errors about multiply defined symbols.

Also note that if you use this macro then the stack trace functionality in the library will be disabled.

### #define DLIB_THREAD_POOL_TIMEOUT <time-in-milliseconds>

If you use dlib to create your threads then you receive the benefit of the dlib dynamic thread pool (Note that the dlib::thread_pool object is something else unrelated to this so don't confuse the two). This pool enables dlib to spawn new threads very rapidly since it draws threads back out of its thread pool when the pool isn't empty.

Thus, when a thread that was created by dlib ends it actually goes back into the dlib thread pool and waits DLIB_THREAD_POOL_TIMEOUT milliseconds before totally terminating and releasing its resources back to the operating system. The default timeout used by this library is 30,000 milliseconds (30 seconds). You may however change this to whatever you like by defining DLIB_THREAD_POOL_TIMEOUT to some new value.

# Compilers

## Visual Studio .NET 2003

You need to link to one of the multithreaded C run-time libraries if you are using the threading stuff. You can do this by setting it in the project options. If you don't you will get some error about _beginthreadex not linking.

## Visual C++ toolkit 2003

This is a pretty good compiler and it is free. But it can be a major pain to use. To get it working you have to download the platform sdk along with the toolkit itself. Both of these things are available from the microsoft web page for free.

Once you have the toolkit and platform sdk installed you should be ready to go. Go to start -> programs -> microsoft visual c++ toolkit 2003 -> Visual C++ Toolkit 2003 Command Prompt. Then switch to the directory that contains your source and the dlib folder.

The following is the command I use and yours should look similar: `cl /O2 -DNO_MAKEFILE /EHsc /MT "%1"`
The %1 should be replaced with the cpp file(s) you want to compile.

You may also have to tell the compiler where the include and lib folders are in the platform sdk. If the above command doesn't work try this one (change paths appropriately for your system): `cl /O2 -DNO_MAKEFILE /EHsc /MT /I"C:\Program Files\Microsoft Platform SDK\Include" "%1" /link /LIBPATH:"C:\Program Files\Microsoft Platform SDK\Lib\"`

## gcc

I generally use gcc version 4.1 but most other versions of gcc work just fine also (except 2.95, see below).

The command line I generally use is "g++ -D NO_MAKEFILE -lnsl -lpthread file.cpp" I think you need to tell it to link nsl to make the threading stuff work right, I honestly can't remember what part of the library requires it I have just been doing it for so long :)

If you are using the sockets stuff then on some platforms you need to supply the -lsocket option. Or if you are using the gui stuff you will need to supply the -lX11 option.

If you compile on solaris you have to give the -lsocket option if you use the sockets API.

## gcc on windows

The commands for gcc on windows are the same as above but you may also have to link (via the -l option) to the following libraries: gdi32, comctl32, user32, ws2_32, or imm32.

# Problem Compilers

Below is a list of the problems I can remember with various compilers. All the problems here are bugs in the compiler and are a pain to write workarounds for (or the workarounds are slow/unsatisfactory) so I have no plans to deal with them. Just avoid these compilers in the given situations.

- Visual Studio .NET and earlier versions
  These compilers don't compile standard C++ very well. Visual Studio 6 doesn't even make any pretenses about being standards compliant. Visual Studio .NET is a lot better but has some bugs with how it implements namespace lookups so most of my code will not compile in Visual Studio .NET. (Note that Visual Studio .NET 2003 works just fine)
- gcc 2.95

  The dir_nav component will not be able to list directories that contain files bigger than 4GB because I had to use stat() rather than stat64() when compiling under this compiler.

  There are also some other problems with gcc 2.95. I believe all the containers work and all the API wrappers but the GUI stuff works. It is sort of touch and go though.