VLFeat - Download > Compiling > Compiling on UNIX-like platforms

# VLFeat.org

Download> Compiling> Compiling on UNIX-like platforms

# 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"
    ...