GNSS-SDR has been successfully built on Ubuntu 14.04-14.10 (32 and 64 bits), Debian 8 (32 and 64 bits), Fedora 18-20 (32 and 64 bits), and Mac OS X 10.9-10.10 systems, and might work on other Unix-like distributions.

In order to create an executable tuned to your system and your host processor, GNSS-SDR uses CMake as a building tool. For Mac OS X users, see below.

Using CMake

Get the ultimate version of the source code by checking out GNSS-SDR's repository:

$ git clone git://github.com/gnss-sdr/gnss-sdr

This will create a folder named gnss-sdr with the following structure:

This will compile, link nd install the softwar receiver on your system. You can create the documentation from the source code by doing:

$ make doc

This will use Doxygen to generate HTML documentation that can be retrieved pointing your browser of preference to gnss-sdr/docs/html/index.html. If a LaTeX installation is detected in your system,

$ make pdfmanual

will create a PDF manual at gnss-sdr/docs/GNSS-SDR_manual.pdf. Finally,

$ make doc-clean

will remove the content of previously-generated documentation.

If there are required dependencies missing, CMake can try to download and build some of them automatically for you. In case of Gflags, Glog, Armadillo and Gtest, they can be downloaded, configured and built 'on-the-fly' when you run 'make', along with the rest of the GNSS-SDR source code. For your convenience, the source code of all those downloaded packages with remain under a newly created folder gnss-sdr/thirdparty. However, installing GNU Radio can be a quite complex process and our CMake scripts cannot do it automatically. By fortune, there are tools that can help you on that, check below. Please note that none of the dependencies downloaded and built when doing 'make' will remain permanently installed on your system. They will be built and linked statically, but not installed. You can install them by following the instructions below, and then they will be found and used the next time you invoke the configuration with 'cmake ../'. Remember that the source code of all those extra dependencies downloaded when doing 'make' will remain under the gnss-sdr/thirdparty folder, so you can go directly there, configure, build and install them.

Manual installation of GNSS-SDR dependencies

Install GNU Radio:

- Downloading, building and installing GNU Radio and all its dependencies is not a simple task. If you are using GNU/Linux, we recommend to use PyBOMBS (Python Build Overlay Managed Bundle System), the GNU Radio install management system that automatically does all the work for you. In a terminal, type:

$ git clone git://github.com/pybombs/pybombs
$ cd pybombs

Configure PyBOMBS:

$ ./pybombs config

You can safely accept the default options but for prefix. We recommend to put /usr/local there. After the configuration, you should get something similar to:

The parameter satisfy_order must be set to rpm,src if you are using Fedora/CentOS/RHEL or any other RPM-based Linux distribution.

Then, you are ready to download and install UHD (the Universal Hardware Driver), GNU Radio and all their required dependencies by doing:

$ sudo ./pybombs install uhd gnuradio

This can take some time (up to two hours to complete, depending on your system), and installs the latest versions of the Universal Hardware Driver (UHD) and GNU Radio in your system, including all their dependencies. In case you do not want to use PyBOMBS and prefer to build and install GNU Radio manually from source, follow instructions at the GNU Radio Building Guide.

After installing GNU Radio, you may want to run volk_profile, a program that tests all known Vector-Optimized Library of Kernels (VOLK) for each Single-Input Multiple-Data (SIMD) architecture supported by the host processor (sse, sse2, sse3, avx, etc.). When finished, it will write to $HOME/.volk/volk_config the best architecture (i.e., the one that provides fastest execution) for each of the VOLK functions. This file is read when using a function to know the best version of the function to execute.

The full stop separated from "cmake" by a space is important. CMake will figure out what other libraries are currently installed and will modify Armadillo's configuration correspondingly. CMake will also generate a run-time armadillo library, which is a combined alias for all the relevant libraries present on your system (eg. BLAS, LAPACK and ATLAS).

Please DO NOT install gtest (do not do "sudo make install"). Every user needs to compile his tests using the same compiler flags used to compile the installed Google Test libraries; otherwise he may run into undefined behaviors (i.e. the tests can behave strangely and may even crash for no obvious reasons). The reason is that C++ has this thing called the One-Definition Rule: if two C++ source files contain different definitions of the same class/function/variable, and you link them together, you violate the rule. The linker may or may not catch the error (in many cases it is not required by the C++ standard to catch the violation). If it does not, you get strange run-time behaviors that are unexpected and hard to debug. If you compile Google Test and your test code using different compiler flags, they may see different definitions of the same class/function/variable (e.g. due to the use of #if in Google Test). Therefore, for your sanity, we recommend to avoid installing pre-compiled Google Test libraries. Instead, each project should compile Google Test itself such that it can be sure that the same flags are used for both Google Test and the tests. GNSS-SDR's building system does the compilation and linking of gtest with its own tests for you; it is only required that you tell the system where the gtest folder that you downloaded resides. Just add to your $HOME/.bashrc file the following line:

export GTEST_DIR=/home/username/gtest-1.7.0

changing /home/username/gtest-1.7.0 by the actual directory where you downloaded gtest.

Release and Debug builds

By default, CMake will build the Release version, meaning that the compiler will generate a faster, optimized executable that will not contain debug symbols (thus making it harder to debug), will not spend time executing assertion checks and will perform a selected subset of logs. This is the recommended build type when using a RF front-end and you need to attain real time. If working with a file (and thus without real-time constraints), you may want to obtain more information about the internals of the receiver, as well as more fine-grained logging. This can be done by building the Debug version, by doing:

That means that the flags passed to the compiler are not focused in obtaining an optimized executable, but to facilitate the work of debugging tools such as gdb. The executable will contain debug symbols, will not be optimized for size or speed and will perform all the assertion checks and logging annotations. This is the preferred variant if you are developing or debugging the code, and where real-time is not a constraint (for instance, reading raw samples from a file instead of from a RF front-end).