As of Oct2020 releases compilation of MonetDB is done using CMake. It can be compiled in any location on your file system and it does not require special (root) permissions.
Note: Before release Oct2020 building the MonetDB software was based on the bootstrap-configure-make pattern, see below.
For latest build instructions please read: dev.monetdb.org/hg/MonetDB/file/tip/documentation/source/build.rst. This document also contains at the bottom specific information for compilation on Windows and macOS.
While the core task of compiling MonetDB itself is extremely simple (on UNIX based platforms), inexperienced users often run into problems caused by many effects of the build environment. The catch is the differences between the target platforms, because not all libraries needed may have been installed by your system administrator. Typical missing components on a binary distribution such as Fedora or Ubuntu are the xxx-dev packages necessary for MonetDB to compile against the package itself.
For Fedora specific packages read: dev.monetdb.org/hg/MonetDB/file/tip/documentation/source/build-fedora.rst.
For Debian specific packages read: dev.monetdb.org/hg/MonetDB/file/tip/documentation/source/build-debian.rst.
In a nutshell, building the software involves commands:
% mkdir build
% cd build
% cmake -DCMAKE_INSTALL_PREFIX=/path/to/install/monetdb /path/to/monetdb/source
% cmake --build .
% cmake --build . --target install
MonetDB is a rather large C-based program, and it sometimes closely interacts with the host system it runs on to achieve the best end results for the user. This makes the code not always as generic as we ultimately would like it to be. Because we understand that these parts of the code are likely suspects for malfunctioning, we try to test our sources on a nightly basis on as many different platforms that we can access. This mainly focuses on different architectures, kernels and libcs, but we also test a couple of Linux distributions, see Nightly testing.
Building from sources before Oct2020
Installing MonetDB from sources is often considered a tedious job. Compilation of MonetDB on the Linux platforms is based on the bootstrap-configure-make pattern. It can be compiled in any location on your file system and it does not require special (root) permissions.
While the core task of compiling MonetDB itself is extremely simple (on UNIX based platforms), inexperienced users often run into problems caused by many effects of the build environment. The catch is the differences between the target platforms, because not all libraries needed may have been installed by your system administrator. Typical missing components on a binary distribution such as Fedora or Ubuntu are the xxx-dev packages necessary for MonetDB to compile against the package itself.
To allow doing the right thing on your system, we use autoconf, automake and libtool to build the software. We aim at being very standard in this respect. In a nutshell, building the software works with the usual ritual:
% configure
% make
% make install
This process often fails for users in the configure step, but the make step may also give problems. We will discuss some of the frequent issues people find here in detail.
For Mac OS X instruction please check this page.
Configure
Calling the configure script will check the system for required files and packages, and determine the capabilities of the system, such that the right approach can be taken in certain parts of the code.
Before calling configure, it is wise to examine all available options this script has by using
% configure --help
In particular the --prefix argument will be necessary to be set in most cases. If you don't know what value to use for the prefix argument, a location in your homedir will typically do, e.g. --prefix=$HOME/MonetDB.
If configure finishes, it gives a conclusion at the end of its output. Be sure to read this carefully, if a component is disabled this means it will not be built and installed. At the time of this writing, you will need at least the monetdb5 and sql components. Unless if you know what you're doing, you should not continue as long as configure reports these components to be disabled.
When a component is disabled, it is usually due to a missing dependency. A dependency is often a library that the component in question relies on for its functionality. The following two dependencies are known trouble makers on most systems that aren't fairly recent: openssl, libxml2 and pcre or libpcre. The former is usually available, but a not recent enough version. The latter two often lack the development headers on systems. You have to install missing dependencies either through the native package management system of your host system, or by compiling and installing them manually. Since this in general differs from package to package, we cannot provide generalized help on this topic. Make sure you install the xxx-dev versions on binary distributions of the necessary packages as well!
Make
After configure has successfully found all it is looking for, make usually churns away for some time, producing quite some output. It can happen that make aborts:
make[3]: *** [something] Error 1
The real error is usually right above this message. If you're looking for help, or want to report a bug, always copy at least about 20 lines above this message, as it gives the necessary context to investigate on the problem.
If you passed --enable-strict to configure, then try to configure with --disable-strict and try make again. This can allow certain type of problems to be ignored, since they are typically non-critical.
Make can fail on a compilation or linking step. The former usually manifests itself by a message from the compiler like
somefile.c:12: 'rl' may be used uninitialized in this function
the latter typically manifest itself by "undefined references". For compilation issues Googling is usually the best action to get a clue on what's going on. The undefined references during linking are often missing libraries, due to missing -L/path/to/dir flags in LDFLAGS. If you have libraries in use that are in a non-standard location (for example because you installed them yourself), make sure you have the proper includes (-I/path/to/include/dir) in your CPPFLAGS environment variable, and the library search paths (-L/path/to/lib/dir and -rpath=/path/to/lib/dir on ELF-based systems e.g. Linux) in your LDFLAGS such that they can be properly found by configure, libtool, the compiler and the linker.
