These instructions explain how to compile VLFeat from sources. While this is necessary in order to develop or modify VLFeat, using the pre-compiled binaries will work in most other cases.

VLFeat is largely self-contained and hence easy to compile. While certain features such as multi-core computation and vector instruction support may require specific compilers, most compilers and environments should be capable of producing fully functional version of the library. Compiling MATLAB or Octave support requires the corresponding applications to be installed too.

- GNU/Linux and Mac OS X compilation instructions
- Windows compilation instructions

%tableofcontents;

# General instructions

Compiling for UNIX-like platforms (e.g. GNU/Linux, Mac OS X) assumes that the standard GNU toolchain is available. In particular, while compilers other than GCC can be used, the compilation scripts require GNU/make.

To compile the library, it is usually sufficient to change to VLFeat root directory, denoted `VLFEATROOT` in the following, and type `make`:

$ cd VLFEATROOT $ make

The make script attempts to automatically detect the host architecture and configure itself accordingly. If the architecture is not detected correctly, it can be specified manually. For instance

$ make ARCH=glnx86

compiles for GNU/Linux 32-bit. `make help` can be used to obtain a list of other useful options. You can also use `make info` to obtain a list of the configuration parameters used by the Makefile, which might allow you do debug any potential issue.

## Compiling MATLAB support

In order for MATLAB support to be compiled, the MATLAB `mex` script must be in the current path. If it is not, its location must be passed to `make` as follows. First, determine MATLAB's root directory by running a MATLAB session and issuing the `matlabroot` command. Let `MATLABROOT` denote the returned path (e.g. `/Applications/MATLAB_R2009b.app/`). The `mex` script is usually located in `MALTABROOT/bin/mex`. Then run the compilation with the command

$ make MEX=MATLABROOT/bin/mex

VLFeat must be compiled for the architecture used by MATLAB (run MATLAB's `computer` command to obtain this information). On Mac OS X it is often necessary to turn on 64-bit support explicitly by setting `ARCH=maci64` as both the 32 and 64 bit versions are plausible targets on 64-bit machines.

## Compiling Octave support

Octave support is still experimental. Similarly to MATLAB, Octave requires compiling MEX files. This can be turned on by passing to make the path to the `mkoctfile` command:

$ make MKOCTFILE=/path/to/mkoctfile

# Mac OS X troubleshooting

## OS X 10.9 Mavericks, Xcode 5, clang, and GCC

Recent changes to Mac OS X toolkit that ships with Xcode have made compilation of VLFeat slightly more complex. Out of the box, Xcode 5.0 on Mac OS X Mavericks, for example, incorporates the clang compiler but not the GCC compiler. While VLFeat has been updated to use clang in this case, it is worth noting that this compiler does not yet support the OpenMP standard, meaning that multi-core computations would be disabled in this case.

Compiling OpenMP can be achieved by using the GCC compiler, for example obtaining it from MacPorts. However, anything more recent that GCC 4.2 will use the MacPorts runtime (C and C++). Since MATLAB links to the OS X native C and C++ runtime, this breaks the compatibility of VLFeat MEX files with MATLAB. In particular, while VLFeat does not use C++, MEX files do as the MEX API is coded in C++ internally (in particular MEX files are coded with the `-fexception` option as MEX API calls can throw exceptions, even though they look like regular C functions). In short, mixing C++ runtimes will cause MATLAB MEX files to crash every time an error is generated.

The easiest solution at present is to use the `gcc-apple-4.2` from MacPorts. Unfortunately, this version does not support AVX instructions, but supports OpenMP and creates binaries that are MATLAB compatible.

# Compile VLFeat in a manner compatible with MATLAB and OpenMP support $ sudo port install apple-gcc42 # Install MacPort's distribution of apple-gcc-42 $ make CC=/opt/local/bin/gcc-apple-42 # compile VLFeat using MacPort's GCC

## OS X 10.6 Snow Leopard, 64-bit, and MATLAB 2009b.

MATLAB 2009b for Snow Leopard has added 64 bit mex support and a corresponding extension `mexmaci64`. VLFeat now supports compiling for this platform, but the architecture must be specified manually when compiling, either like:

$ make ARCH=maci64

or

$ make ARCH=maci

Unfortunately, MATLAB 2009b's `mex` script has a bug that must be manually fixed in order for this procedure to work correctly. It is recommend to make backup of the `mex` script before attempting this. Th fix the bug, edit the `MATLABROOT/bin/mex` script by cutting the line:

get_arch # Call $MATLAB/bin/util/arch.sh

and pasting it after the processing of options:

... shift done #PASTE get_arch call here get_arch # Call $MATLAB/bin/util/arch.sh if [ $v7_compat -eq 1 ] ; then fc_flags="$fc_flags -DMX_COMPAT_32" ...

For Windows, the library bundles an NMake makefile (`Makefile.mak`). In order to use it, you must edit Makefile.mak to adjust the values of a number of configuration variables to match your setup. Once you have done that, start the Visual Studio Command Prompt and type

$ nmake /f Makefile.mak # for the Windows 64 target $ nmake /f Makefile.mak ARCH=win32 # for the Windows 32 target

For Windows platform, it is also possible to compile just the MATLAB MEX files from within MATLAB (using the `vl_compile` command). This is meant to help less experienced users that may need to recompile the mex file due to binary incompatibilities with older MATLAB versions.

# Windows troubleshooting

syntax error: '=' unexpected:

  Use `nmake /f Makefile.mak`. Without `/f`, nmake will default to the wrong makefile.

'long' followed by 'long' is illegal:

  This error is usually caused by attempting to compile outside of the Visual Studio Command Prompt.