You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
=== WHAT IS THIS?
* quickly build the entire Osmocom core network stack from source, with a
generated top-level makefile (see the rest of this README file below).
* quickly configure, launch and tear down an entire Osmocom core network on
your box (see net/README).
=== Quick Start
sudo apt install \
build-essential gcc g++ make automake autoconf libtool pkg-config \
libtalloc-dev libpcsclite-dev libortp-dev libsctp-dev libssl-dev libdbi-dev \
libdbd-sqlite3 libsqlite3-dev libpcap-dev libc-ares-dev libgnutls28-dev \
libsctp-dev sqlite3 libusb-1.0-0-dev libmnl-dev libsofia-sip-ua-glib-dev
./gen_makefile.py default.opts iu.opts no_dahdi.opts -I -m make
- 'make' will ask for sudo password to run 'make install' and 'ldconfig'.
To run non-interactively:
- 'make install':
chown $USER: /usr/local
Then call gen_makefile.py once without the -I option
echo "$USER ALL= NOPASSWD: /sbin/ldconfig" > /etc/sudoers.d/ldconfig
This provides a set of top-level makefiles to build variants of the Osmocom
source trees. It is inteded for the core network components and related
projects, but works generically.
The idea is to have all your Osmocom git clones in ./src, while keeping one or
more separate build trees in ./make-*.
Run ./gen_makefile.py with a choice of choice of configure options.
CN with full 2G and 3G support:
./gen_makefile.py default.opts iu.opts -m make
Other make targets exist for specific use cases:
Build the CN, OsmoBSC, OsmoBTS and OsmoTRX (default, e.g. when connecting
to an USRP)
Build the CN and OsmoBSC (e.g. when connecting to an external sysmoBTS)
Build only the OsmoMSC project and its dependencies (this can be used for
any project in all.deps).
Clone the osmo-ttcn3-hacks git repository (it cannot be built by osmo-dev,
but cloning it is still useful.)
If you make modifications in one of the source trees, this Makefile will pick
it up, rebuild the project and also rebuild all dependencies (according to
If you modify the all.deps or *.opts file, you can easily run 'make regen' in a
make-* subdir to regenerate the Makefile from the same files.
In your make-* subdir there are empty status files that are touched for every
completed make target. From these, 'make' can detect what needs to be rebuilt.
You can manually remove them to force a rebuild of a specific target.
For example, if you 'rm .make.libosmocore.autoconf', libosmocore and all
projects depending on libosmocore will be rebuilt from scratch.
For more details on the *.opts and all.deps syntax, read the docs at the top of
It is also easily possible to keep sources and build trees in various
configurations, see the command line options of ./gen_makefile.py.
=== Install in /usr
By default, the Osmocom install prefix is /usr/local, while (currently) the
default systemd *.service files expect binaries installed in /usr/bin. To
install in /usr instead, use prefix_usr.opts, which sets --prefix=/usr.
=== Systemd Service Files
If you encounter problems installing *.service files, no_systemd.opts may help:
Systemd recommends installing service files in the distribution's single
service file location; that may sound sane, but if that location is
/lib/systemd/system, that means even a --prefix=/home/private/prefix ends up
trying to install service files system-wide in /lib/systemd/system, making all
attempts to install to a user-writable location fail.
no_systemd.opts disables installing *.service files.
=== Build Environment
For dependencies, see the "External dependencies" on:
If /usr/local/ is not writable by your user, pass the --sudo-make-install
option to gen_makefile.py above (a custom --prefix is not yet supported).
If your system doesn't have this by default, you will need:
to your environment. To use the installed binaries after installation, also
Remove osmocom built binaries and headers from given prefix,
default is /usr/local.
Find other useful scripts in src/, see src/README.
Run a given testsuite with docker, so it behaves exactly the same as when
jenkins runs it , but use osmo-dev to build all related Osmocom components
and the testsuite, and mount them inside the docker containers. After building
the docker containers for the first time (which takes rather long), this gives
short test cycles: just modify something, run the script again and the relevant
objects will be built directly, already built objects do not need to be
rebuilt. (This is a big speed improvement over just using docker containers as
you don't need to push your sources to a git server first, have the docker
containers fetch the git sources and build the modified component from scratch
The docker containers are used, so we don't have to maintain a second set of
configs which works without docker (that was tried before, and found not to be
IMAGE_SUFFIX=latest ./ttcn3/ttcn3.sh mgw
More about the testsuites:
It's possible to run TTCN-3 test cases without using Docker. This directory
contains scripts for starting a testsuite and the related binaries in a tmux
session. For example, ttcn3-bsc-test.sh does the following:
* Starts osmo-bsc, osmo-stp, and three instances of osmo-bts-omldummy.
* Prepares a command for execuring the test suite.
When using sanitize.opts, osmo-trx is not built with the address sanitizer
enabled. Linking a sanitizer-enabled libosmocore will not work.