= Building GPSD from source =

This is a guide to building GPSD from a bare source tree. It includes

guidance on how to cross-build the package.

Some hints for people building binary packages are in packaging/readme.txt.

(This file is marked up in asciidoc.)

== Quick start ==

Under Linux, assuming you have all your build prerequisites in place,

this line will do:

scons && scons check && sudo scons udev-install

If you get any errors, you need to read the detailed instructions that follow.

If 'scons' fails, it is possible that your target system has moved to

Python 3 as its default 'python' interpreter, but you can work around

it by saying "python2 /usr/bin/scons" or something similar. GPSD's

own Python scripts assume that "#!/usr/bin/env python2" will invoke a

Python 2 interpreter.

== Supported platforms ==

Native-build success should be expected on the following platforms,

provided you have the prerequisites listed in the next section

installed:

* Any desktop or server Linux distribution.

* OpenWRT and derivatives such as CeroWRT.

* FreeBSD, NetBSD, OpenBSD

* Android, using the official Google toolchain from the NDK

We consider failure to build and function on any of these platforms

a serious bug; if you encounter it, please complain on the

development list.

Port difficulty to any system conforming to POSIX-2001.1 should be minimal.

A Cygwin port is in progress but not complete.

Cross-compilation to embedded Linuxes (in addition to the OpenWRT family)

is usually fairly straightforward. An illustrative build transcript

is included at the end of this file.

== Check your build prerequisites ==

Necessary components for any build:

|============================================================================

|C compiler | gpsd and client library are written in C

|Python 2.x, x >= 6 | some code is generated from python scripts

|scons | for executing the build recipe

|============================================================================

Note: There must be a Python 2 interpreter named 'python' in your path,

or the regression tests will fail. On some systems you might need to

arrange this by putting symlink in a local directory on $PATH.

=== C compiler ===

C99 conformance is required in the compiler. The C code depends on one

C11 feature (supported by GCC, clang, and pretty much any C compiler

that also speaks C++): anonymous unions. We could eliminate these,

but the cost would be source-level interface breakage if we have to

move structure members in and out of unions.

Some portions of the code using shared-memory segments are improved by

the C11 stdatomic.h features for lockless concurrency. These are: the

SHM export mode in shmexport.c, the code for writing clock corrections

to NTP in ntpshmwrite.c, and the code for reading NTP corrections in

ntpshmread.c. These features have been supported in GCC since 4.7 and

clang since 3.1.

GPSD is normally built and tested with GCC. Do not compile with a version

older than 4.1.1; there are several known issues with older versions,

including (a) non-standards-conformant floating-point generation that

messes up regression testing, (b) a compiler bug affecting RTCM2 code

generation, (c) the option -Wno-missing-field-initializers is

unavailable, leading to a flood of warnings (this is due to generated

code and cannot be fixed).

clang produces a gpsd that passes all regression tests.

=== Python ===

You will need Python 2.5 or later for the build.

While Python is required to build GPSD from source (the build uses

some code generators in Python), it is not required to run the service

daemon. In particular, you can cross-compile onto an embedded system

without having to take Python with you.

You will need both basic Python and (if your package system makes the

distinction) the Python development package used for building C

extensions. Usually these are called "python" and "python-dev". You

will know you are missing the latter if your compilation fails

because of a missing Python.h.

The xgps test client requires the following Python extensions:

|============================================================================

|gobject | GNOME object introspection library

|pygtk | Python bindings for GTK

|===========================================================================

=== Scons ===

You will need scons version 2.3.0 (from 2013-03-02) or later to build the code.

=== Optional build components ===

Having the following optional components on your system will enable

various additional capabilities and extensions:

|============================================================================

|C++ compiler | allows building libgpsmm C++ wrapper for client library

|Qt 4.53+ | allows building libQgpsmm C++ wrapper for client library

|libcap | Capabilities library, allows 1PPS support under Linux

|curses | curses screen-painting library, allows building cgps

|============================================================================

If you have libusb-1.0.0 or later, the GPSD build will autodetect

this and use it to discover Garmin USB GPSes, rather than groveling

through /proc/bus/usb/devices (which has been deprecated by the

Linux kernel team).

You can build libQgpsmm if you have Qt (specifically QtCore and

QtNetwork modules) version 4.5.3 or higher. You will also need a C++

compiler supported by Qt (tested on GCC 4.4.0/mingw on Windows and GCC

4.1.2 on linux). Please refer to Qt's documentation at

http://qt.nokia.com/doc/4.6/platform-specific.html for platform

specific building documentation

For working with DBUS, you'll need the DBUS development

headers and libraries installed. Under Debian/Ubuntu these

are the packages libdbus-1-dev and libdbus-glib-1-dev.

Under Ubuntu, the ncurses package you want is libncurses5-dev. Under

Fedora, it's ncurses-devel. Depending on how your distribution

packages ncurses you may also require libtinfo5, a separate terminfo

library.

On some older versions of Ubuntu (notably 11.10) there is a packaging

defect that may cause your build to blow up in SCons. It's a missing

package info file for the tinfo library. To fix this, install the file

packaging/tinfo.pc in /usr/lib/pkgconfig/tinfo.pc. 13.10 fixed this.

We've seen a report that compiling on the Raspberry Pi fails with

a complaint about curses.h not being found. You need to install

Raspbian's curses development library if this happens.

For building from the source tree, or if you change the man page

source, xslt and docbook xsl style files are used to generate nroff

-man source from docbook xml. The following packages are used in this

process:

|============================================================================

|libxslt | xsltproc is used to build man pages from xml

|docbook-xsl | style file for xml to man translation

|xmlto | DocBook formatter program

|asciidoc | DocBook front end with lighter markup

|============================================================================

The build degrades gracefully in the absence of any of these. You should

be able to tell from scons messages which extensions you will get.

Under Ubuntu and most other Debian-derived distributions, an easy way

to pick up the prerequisites is: "apt-get build-dep gpsd"

If you are custom-building a Linux kernel for embedded deployment, you

will need some subset of the following modules:

|============================================================================

|pl2303 | Prolific Technology, Inc. PL2303 Serial Port

|ftdi_sio | FTDI 8U232AM / FT232

|cypress_m8 | M8/CY7C64013

|cp210x | Cygnal Integrated Products devices

|garmin_gps | Garmin USB mice including GPS-18

|cdc_am | USB Communication Device Class Abstract Control Model interface

|============================================================================

These are listed in rough order of devices covered as of 2013; the

PL23203 by itself accounts for over 70% of deployed USB mice. We

recommend building with pl2303, ftdi_sio, cypress_m8, and cp210x.

We've receive a bug report that suggests the Python test framework

requires legacy PTY support (CONFIG_LEGACY_PTYS) from the Linux

kernel. You should make sure you're in the 'dialout' group in order

to have permission to use these devices.

== How to build the software from source ==

To build gpsd for your host platform from source, simply call 'scons'

in a working-directory copy. (Cross-build is described in a later

section.)

To clean the built files, call 'scons -c' . To clean scons' cache,

call 'scons sconsclean'. Doing both should return your working directory

to a near pristine state as far as building is concerned. Some user

created files may remain, and source code changes will not have been

reverted..

You can specify the installation prefix, as for an autotools build, by

running "scons prefix=<installation_root>". The default value is

"/usr/local". The environment variable DESTDIR also works in the

usual way.

If your linker run fails with missing math symbols, see the FIXME

comment relating to implicit_links in the scons recipe; you probably

need to build with implicit_link=no. If this happens, please report

your platform, ideally along with a way of identifying it from Python,

to the GPSD maintainers.

If, while building, you see a complaint that looks like this:

--------------------------------------------------------------------

I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd

--------------------------------------------------------------------

it means the xmlto document formatter is failing to fetch a stylesheet it

needs over the network. Probably this means you are doing a source

build on a machine without live Internet access. The workaround

for this is to temporarily remove xmlto from your command path so GPSD

won't try building the documentation. The actual fix is to install

DocBook on your machine so there will be a local copy of the

stylesheet where xmlto can find it.

After building, please run 'scons check' to test the correctness

of the build. It is not necessary to install first. Python is

required for regression tests. If any of the tests fail, you probably

have a toolchain issue. The most common such problem is failures of

strict C99 conformance in floating-point libraries.

Once you have verified that the code is working, "scons install"

will install it it in the system directories. "scons uninstall" will

undo this. Note: because scons is a single-phase build system, this

may recompile everything. If you want feature-configuration options,

you need to specify them here.

To enable hotplugging of USB GPSes under Linux, you may do 'scons

udev-install' to put the appropriate udev rules and wrapper files in

place.

You will need php and php-gd installed to support the PHP web page.

included with the distribution. To install it, copy the file

'gpsd.php' to your HTML document directory. Then see the

post-installation instructions in INSTALL for how to configure it.

== The leapseconds cache ==

Early in your build, the recipe will try to go over the Internet to

one of several sources of current data on the leap-second offset in

order to ensure that the file leapseconds.cache is up to date. This,

in turn, is used to build a timebase.h include file.

This procedure may fail if you are building in a network that

requires an authenticating web proxy. If that occurs, the build will

time out with a warning and a suggestion to use the leapfetch=no build

option.

Building with leapfetch=no may, in unusual circumstances, result in

reported GPS time being off by a second or more. The circumstances

are:

1. It has been less than 20 minutes since power-up; the GPS has

not yet received the current leapsecond offset as part of the

periodic ephemeris download.

2. One or more leap-second offset increments have been issued between

when your GPSD source tree was cloned from the repository (or

leapsecond.cache was later updated) and now. Leap-second

increments, compensating for minute and unpredictable changes in

the Earth's rotation, are occasionally issued by international time

authorities.

Note that the same failure can occur with any GPSD installation. But

by refreshing leapseconds.cache you reduce the error window for

leap-second offset bumps to affect your installation so that it begins

as late as possible, at your build time rather than from when the

source tree was copied.

If you have had a leap-second transition, the following regression tests

will break:

bu303-climbing.log

bu303-moving.log

bu303-nofix.log

bu303-stillfix.log

bu303b-nofix.log

italk-binary.log

navcom.log

ublox-aek-4t.log

ublox-lea-4t.log

ublox-sirf1.log

There is no help for this other than a test rebuild. The problem is

that these devices rely on the build-time leap-second offset; you'll

see times one second off. Other GPSes either return

leap-second-corrected time or the test loads include a

leapsecond-offset report before any time is reported.

== Optional features ==

By giving command-line options to scons you can configure certain rarely-used

optional features in, or compile standard features out to reduce gpsd's

footprint. "scons --help" will tell the story; look under "Local Options"

and consult the source code if in doubt.

Here are a few of the more important feature switches. Each description

begins with the default for the switch.

pps=yes: for small embedded systems and those without threading,

it is possible to build gpsd without thread support if you build

with pps=no. You'll lose support for updating the clock from PPS

pulses.

dbus_export=no: for systems using DBUS: gpsd includes support for

shipping fixes as DBUS notifications, compiled in by default. This

may lead to complaint messages during testing on systems that don't

support DBUS. Build with the option "dbus_export=no" to disable it

qt=yes: libQgpsmm is a Qt version of the libgps/libgpsmm

pair. Thanks to the multi-platform approach of Qt, it allows the gpsd

client library to be available on all the Qt supported platforms.

Please see http://qt.nokia.com/doc/4.6/supported-platforms.html for a

status of Qt supported platforms as of version 4.6.

minimal=yes: people building for extremely constrained environments

may want to set this. It changes the default for all boolean (feature)

options to false; thus, you get *only* the options you specify on the

command line. Thus, for example, if you want to turn off all features

except socket export and nmea0183,

------------------------------------------------

scons minimal=yes socket_export=yes nmea0183=yes

------------------------------------------------

will do that.

== Port and toolchain testing ==

'scons check' will run a comprehensive regression-test suite. You

should do this, at minimum, every time you build from source on a new

machine type. GPSD does enough bit-twiddling and floating point that

it is very sensitive to toolchain problems; you'll want to be sure

those aren't going to bite you in production.

So the tests will run fast and be easy to do often, we make the test

framework shove data through the pty and socket layers *way* faster

than would ever occur in production. If you get regression-test

failures that aren't repeatable and look like the test framework is

sporadically failing to feed the last line or two of test loads, try

using the slow=yes option with scons check. If that fails, try

increasing the delay constants in gps/fake.py. If you have to do this,

please report your experience to the GPSD maintainers.

For instructions on how to live-test the software, see the file INSTALL.

== Reverting to a clean state ==

The scons equivalent of 'make clean' is 'scons -c' or 'scons

--clean'. This will revert your source tree to a clean state nearly as

though you had just cloned or downloaded it; some scons housekeeping

stuff is left in place.

If you interrupted a regression test, 'scons testclean' will remove

generated test programs.

You can run 'scons sconsclean' to temove most of the configuration

state that scons keeps. Be aware, however, thatr doing this can

confuse scons; you may need to run 'scons --config=force' afterwards

to make your build succeed.

== Notes on Android:

Samuel Cuella reports:

I use the official google toolchain from the Android NDK (Native

Development Kit). You can also use the toolchain from code sourcery I

guess. I cross-compile from a "regular" (with GNU userland) linux box.

People who port software from linux to android tend to use either the

NDK or code sourcery's.

If you are going to include "official" guidelines, I would go for

recommending the official toolchain from the NDK.

Here are the scons switches I use:

scons wordsize=32 snapshot=off arch=arm sample=shell

scons -j3 prefix=/usr libdir=$prefix/lib udevdir=/lib/udev

gpsd_user=gpsd gpsd_group=uucp socket_export=1

nmea0183=1 sirf=1

With the following environment variables:

TOOL_HOME=/home/samuel/android-official-last/

export TOOL_PREFIX=${TOOL_HOME}/bin/arm-linux-androideabi

export CXX=$TOOL_PREFIX-g++

export AR=$TOOL_PREFIX-ar

export RANLIB=$TOOL_PREFIX-ranlib

export CC=$TOOL_PREFIX-gcc

export LD=$TOOL_PREFIX-ld

export CCFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=vfp"

export ARM_TARGET_LIB=${TOOL_HOME}/sysroot

scons wordsize=32 snapshot=off arch=arm sample=shell

== Cross-building ==

The scons recipe is intended to support cross-building, in particular

for embedded deployment of the software. A session transcript

illustrating how to do that, with some routine messages suppressed and

replaced with [...], follows. The script assumes you're cloning from the

GPSD project site or a mirror. Notes and explanation follow the transcript.

----

$ git clone [...]

Cloning into gpsd...

[...]

$ cd gpsd

$ cp ../.scons-option-cache .

$ cat .scons-option-cache

libgpsmm = False

libQgpsmm = False

python = False

prefix = '/work/buildroot/output/staging/usr/'

sysroot = '/work/buildroot/output/staging/'

target = 'arm-indigo-linux-gnueabi'

$ scons

scons: Reading SConscript files ...

[...]

Altered configuration variables:

libgpsmm = False (default True): build C++ bindings

libQgpsmm = False (default True): build QT bindings

python = False (default True): build Python support and modules.

prefix = /work/buildroot/output/staging/usr/ (default /usr/local): installation directory prefix

sysroot = /work/buildroot/output/staging (default ): cross-development system root

target = arm-indigo-linux-gnueabi (default ): cross-development target

scons: done reading SConscript files.

scons: Building targets ...

substituter(["jsongen.py"], ["jsongen.py.in"])

chmod -w jsongen.py

chmod +x jsongen.py

rm -f ais_json.i && /usr/bin/python jsongen.py --ais --target=parser > ais_json.i && chmod a-w ais_json.i

Creating 'gpsd_config.h'

arm-indigo-linux-gnueabi-gcc -o ais_json.os -c --sysroot=/work/buildroot/output/staging/ -Wextra -Wall -Wno-uninitialized -Wno-missing-field-initializers -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith -Wreturn-type -D_GNU_SOURCE -O2 -fPIC ais_json.c

arm-indigo-linux-gnueabi-gcc -o daemon.os -c --sysroot=/work/buildroot/output/staging/ -Wextra -Wall -Wno-uninitialized -Wno-missing-field-initializers -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith -Wreturn-type -D_GNU_SOURCE -O2 -fPIC daemon.c

Creating 'gpsd.h'

[...]

chmod -w maskaudit.py

chmod +x maskaudit.py

rm -f gps_maskdump.c && /usr/bin/python maskaudit.py -c . > gps_maskdump.c && chmod a-w gps_maskdump.c

arm-indigo-linux-gnueabi-gcc -o gps_maskdump.os -c --sysroot=/work/buildroot/output/staging/ -Wextra -Wall -Wno-uninitialized -Wno-missing-field-initializers -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith -Wreturn-type -D_GNU_SOURCE -O2 -fPIC gps_maskdump.c

[..]

scons: done building targets.

$ file gpsd

gpsd: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.36, not stripped

----

The author of this transcript notes:

The sysroot option tells the compiler and linker to use libraries and

headers from the given path as if they were placed at / prefix. During

this build the option allows linking with target ncurses (with the option

of having more packages at the --sysroot path) and including correct

headers without specifying -I and -L options.

In the options cache file gpsd is configured to install to

/work/buildroot/output/staging/usr path, so gpsd clients could be

compiled against libgps.so using /work/buildroot/output/staging as

sysroot option.

"arm-indigo-linux-gnueabi" as target means that

arm-indigo-linux-gnueabi-gcc and related tools are available in PATH;

your cross-compiler is likely to have a different target prefix.

You may also find it useful to set manbuild=no.

== Autostarting the daemon ==

The preferred way to start gpsd is on-demand by a hotplug script

detecting USB device activations. Look at the gpsd.rules and

gpsd.hotplug files to see how this is accomplished. Relevant

productions in the build recipe are "udev-install" and

"udev-uninstall"; relevant build options include "udevdir".

If you for some reason need to start gpsd unconditionally at

boot time (in particular, if you need to support RS232 devices)

there's a model init.d script under packaging/deb and a systemd

setup under systemd/.

// end