I recently had a hard time compiling the QuantLib Python bindings. The following instructions are based on a blog entry for QuantLib 1.2 by Euangelos Linardos which unfortunately is no longer online. I stumbled over some additional obstacles in the installation process though which took me a couple of days to overcome. So this post is a more detailed installation walk-through with what may go wrong at which moment in the build process.

[alert type=”info” icon-size=”normal”]There is a more recent article on compiling QuantLib SWIG bindings for Python.[/alert]

Step One: Prerequisites

First thing you need is lots of free RAM memory and lots of disk space as it turns out that the compilation of these SWIG bindings requires even more heavy lifting than the compilation of the core QuantLib itself. Be sure that:

• you have at least 15 GB of hard disk space on partition holding /usr/local/lib
• you have at least 4 GB of RAM (see below for workaround)

The compilation itself is not different from any ordinary cook-book recipe to compile QuantLib for a Debian-flavoured Linux machine. Make sure your system has the following packages installed before you proceed:

• build-essentials
• libboost-dev
• python-dev

Finally you need the download the sources of QuantLib itself and of the QuantLib-SWIG bindings:

Step Two: Compile QuantLib

What differs from ordinary QuantLib installations is that you have to untar the QuantLib sources to /usr/local/lib. Root privileges are needed to work in that directory.

This was my first error which cost me a lot of time. As I found it counterintuitive to run configure and make in a privileged system location, I went astray from the instructions in the blog by Euangelos and tried the default ./configure – make – sudo make install procedure.

QuantLib will compile just fine with that default procedure, but the compilation of the SWIG bindings for Python will fail later complaining that essential things under the ql source directory cannot be found. Once again: Your sources must be untared to /usr/local/lib and you need to be superuser.

Additionally, keep in mind that there should be enough space left on your disk partition. Compiling QuantLib can easily consume 5 GB – so you are normally safe if df -h /usr shows 10 GB or more.

Step Two: Compile QuantLib-SWIG for Python

Once  you have QuantLib installed, you download and build your QuantLib-SWIG bindings. Again, all this must happen in the /usr/local/lib directory with root privileges, and you should have at least 5 GB left on your partition.

Compiling SWIG bindings needs lots of RAM

In case your machine has less than 4 GB RAM, your installation will most probably freeze. This happened when I first tried to compile the Python bindings on my budget notebook with 3.6 GB RAM and the 64-bit version of Ubuntu 14.04LTS Desktop installed.

When I saw the free RAM sucked away by cc1plus, I first suspected some kind of memory leak. It took me another day of fiddling around with different QuantLib versions on different Linux systems in virtual machines to find out that this is no bug or memory leak but that compiling those wrappers simply draws heavily on your RAM and if you don’t have enough, your machine will become unresponsive:

The freeze is probably caused (was definitely caused, in the case of the original poster) by the exhaustion of the available memory. The wrappers are huge, weighing at about 10 MBytes, and compiling them requires quite a few resources. […]. If you’re using a physical machine and you can’t, try disabling optimizations to make the compilation process less demanding. You can do this by passing CXXFLAGS=-O0 to either ./configure or make.

An alternative way to disabling the compiler optimizations which worked for me was to launch Ubuntu in console mode without any graphical desktop. This freed enough RAM  for the build process to work. For Ubuntu 14.04, there is an instruction how to temporarily modify Ubuntu’s grub bootloader so that Ubuntu is launched in console mode the next time you boot.

In Ubuntu 16.04 LTS, the procedure you can force booting into console mode by

You will get a couple of warnings after disabling lightdm which you can Keep in mind that this changes the boot procedure not once but for any further boot in the future. You therefore have to reverse into lightdm boot after having compiled the SWIG bindings (see Step 4: clean up section).

[alert type=”info” icon-size=”normal”]While compiling the SWIG bindings from the booted console worked in Ubuntu 14.04 with QuantLib 1.6, it is no longer working under Ubuntu 16.04 and QuantLib 1.9. In case you run into similar RAM shortages, my advice is to switch of the compile optimization by the help of the CXXFLAGS.[/alert]

Build the SWIG bindings

Once you are in an environment which has enough RAM to compile the bindings, just issue the following commands. Don’t forget to export the path to the QuantLib sources. Before you configure and build:

On my machine, the make process took a while even though I was in console mode and I used sudo make -j 3 -C Python to build on two cores simultaneously (as my notebook is a Celeron 877 CPU, there were no more than two cores…) – So depending on your machine, it might make sense to wait for at least 10 minutes before you declare the compile process “stuck”.

Step Three: Run Python Setup Script

Once you successfully built the wrappers, you run the setup.py script the usual way:

If everything worked fine, you should be able to import QuantLib in Python:

Step Four: Clean up

As I initially mentioned, I find it counterintuitive to keep fiddle around with source files and build environments in a directory like /usr/local/lib. Besides, the remainders from the compilation will occupy a whopping 6.5 GB on your hard drive. So there is no harm in cleaning up a bit. – Don’t worry: Removing the build directories will not affect QuantLib or QuantLib for Python. Just make sure you do not delete the libQuantLib files or the python directories which reside directly under /usr/local/bin:

If we are running Ubuntu 16.04 and compiled from the console, we finally have to put it back into graphic boot: