TSDuck v3.37-3645
MPEG Transport Stream Toolkit
Loading...
Searching...
No Matches
Building TSDuck

TSDuck can be built on Windows, Linux, macOS and BSD systems.

Support for Dektec devices, DVB tuners and HiDes modulators is implemented only on Windows and Linux. MacOS and BSD systems can only support files and networking for TS input and output.

Some protocols such as SRT and RIST require external libraries which may not be available on all platforms or all versions of a specific distro.

Tested systems

TSDuck has been tested on the following operating systems on at least one CPU architecture.

OS Variants
macOS
Windows
Linux Ubuntu, Debian, Raspbian, Mint, Fedora, Red Hat, CentOS, Rocky, Alma, openSUSE, Arch, Alpine, Gentoo
BSD FreeBSD, OpenBSD, NetBSD, DragonFlyBSD

TSDuck has been tested on the following CPU architectures on at least one operating system.

Architecture Bits Endian
Intel x86 32 Little
Intel x86-64 64 Little
Armv7 32 Little
Armv8 64 Little
MIPS 32, 64 Little
RISC-V 64 Little
PowerPC 64 Big
IBM s390x 64 Big

Note: Some tests were done by contributors and were not verified. Some tests were performed using qemu, on an emulated platform, not a physical CPU. This is the case for RISC-V, PowerPC, IBM s390x.

TSDuck has been tested with the following compilers on at least one operating system.

Compiler OS Minimum version
GCC Linux, BSD 11.0
Clang Linux, macOS 5.0
MSVC Windows Visual Studio 2017 15.8

The minimum version of each compiler is driven by a correct implementation of C++17.

Unix systems (Linux, macOS, BSD)

Pre-requisites

Operations in this section must be run once, before building TSDuck for the first time one a given system.

Execute the shell-script scripts/install-prerequisites.sh. It downloads and installs the requested packages which are necessary to build TSDuck. The list of packages and how to install them depend on the operating system distribution and version.

If you intend to use exclusion options in the make command line (for instance NOSRT=1 NORIST=1), specify them to scripts/install-prerequisites.sh too. This will prevent the installation of unused libraries. Additional supported exclusion options are NOJAVA=1 NODOXYGEN=1.

Currently, the script supports the following operating systems:

  • macOS
  • Ubuntu
  • Debian
  • Raspbian (Debian for Raspberry Pi)
  • Fedora
  • Red Hat Enterprise Linux
  • CentOS
  • Alma Linux
  • Rocky Linux
  • openSUSE Linux
  • Arch Linux
  • Alpine Linux
  • Gentoo
  • Linux Mint
  • FreeBSD
  • OpenBSD
  • NetBSD
  • DragonFlyBSD

Since all packages are pulled from the standard repositories of each distro, there is generally no need to re-run this script later. The packages will be updated as part of the system system updates. Note, however, that a new version of TSDuck may require additional dependencies. In case of build error, it can be wise to run scripts/install-prerequisites.sh again and retry.

C++ compiler requirements

C++ language version

TSDuck now requires a C++17 compliant compiler. GCC is supposed to support C++17 from version 8 onwards. Clang needs version 5 at least.

However, building TSDuck with GCC versions 8 to 10 fails because of bugs in the compiler. C++17 support in GCC really works starting with version 11.

All recent Linux distros use GCC 11, 12 or 13. Some older distros which come with older GCC versions may propose alternative GCC packages with more recent versions.

If your distro is too old and doesn't provide any GCC 11 or clang 5 package, then you cannot build TSDuck version 3.36 and higher. On such systems, the highest TSDuck version which can be built is 3.35. This is the cost of obsolescence...

Using clang as an alternative to GCC

Another alternative is to use LLVM/clang. Most distros with old versions of GCC provide decently recent versions of clang. To force a build with LLVM/clang instead of GCC, defined the make variable LLVM:

$ make LLVM=1 ....

However, when the installed GCC is really old (typically before GCC 8), using clang may not work either because clang uses the GCC C/C++ standard libraries and their header files. If the GCC issue is a compilation issue on GCC 8 to 10, using clang may work. With older versions of GCC, using clang probably does not work because the corresponding standard library does not contain the C++17 features.

RedHat example

Starting with RedHat Entreprise Linux 9, all GCC versions correctly support C++17.

However, RedHat Entreprise Linux 8.8 comes with GCC 8.5.0. You can install and use GCC 11 using the following commands:

$ sudo dnf install gcc-toolset-11-gcc-c++ gcc-toolset-11-libatomic-devel
$ source /opt/rh/gcc-toolset-11/enable
$ make ...

The first command installs the GCC 11 packages. The second command defines the required environment variables in the current process. The last one builds TSDuck. Note that the GCC 11 packages are available in the AppStream repository. Make sure to have activated it first.

Other Linux distros

Older versions of other distros such as Ubuntu, Debian and others have equivalent alternative packages for GCC 11, with different names, when they come with an older version of GCC.

If there is no enable script (as in the example above) to setup the environment, you need to define the following variables, either as environment variables or on the make command line. The provided values are examples only and may be different in specific environments.

$ make CXX=g++-11 CC=gcc-11 GCC=gcc-11 CPP="gcc-11 -E" AR=gcc-ar-11 ...

Since make uses the environment for the initial values of its variables, it is also possibe to define them as environment variables in some initialization script instead of using such a complex make command..

NetBSD example

As of this writing, the most recent version of NetBSD is 9.3, which comes with GCC 7.5. More recent GCC packages are available. To install GCC 13:

$ sudo pkgin install gcc13

The compilation environment is installed in /usr/pkg/gcc13. Using GCC 13 is simply enabled by adding /usr/pkg/gcc13/bin at the beginning of the PATH:

$ export PATH="/usr/pkg/gcc13/bin:$PATH"

DragonFlyBSD example

As of this writing, the most recent version of DragonFlyBSD is 6.4.0, which comes with GCC 8.3. Even though DragonFlyBSD is supposed to be based on FreeBSD, its GCC version is way behind FreeBSD version 14.0 which comes with GCC 12.2.

More recent GCC packages are available for DragonFlyBSD. To install GCC 13:

$ sudo pkg install gcc13

However, because all *BSD systems are carefully incompatible between each other, using the alternative compiler is very different from NetBSD. Building TSDuck:

$ gmake CXX=g++13 CC=gcc13 GCC=gcc13 CPP="gcc13 -E" AR=gcc-ar13 LDFLAGS_EXTRA="-Wl,-rpath=/usr/local/lib/gcc13" ...

Since make uses the environment for the initial values of its variables, it is also possibe to define them as environment variables in some initialization script instead of using such a complex make command..

Hardware device libraries

Dektec DTAPI : The command make at the top level will automatically download the LinuxSDK from the Dektec site. There is no manual setup for DTAPI on Linux. Note that the Dektec DTAPI is available only for Linux distros on Intel CPU's with the GNU libc. Non-Intel systems (for instance ARM-based devices such as Raspberry Pi) cannot use Dektec devices. Similarly, Intel-based distros using a non-standard libc (for instance Alpine Linux which uses musl libc) cannot use Dektec devices either.

Vatek API : On Linux, the command make at the top level will automatically download the Linux version of the Vatek API from the GitHub. There is currectly no Linux package for the Vatek API in the standard distros. On Windows and macOS, binary packages are available and are installed by the install-prerequisites scripts. Using Vatek devices on BSD systems is currently not supported but should work if necessary (accessing Vatek devices is performed through libusb and not a specific kernel driver).

BSD systems

On FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, the standard BSD make command uses an old syntax. The makefiles in the TSDuck project use a GNU Make syntax and are not compatible with the BSD make command. As part of prerequisites for BSD systems, GNU Make is installed under the name gmake. In all build commands in this page, when make is mentioned, use gmake on all BSD systems.

Building the TSDuck binaries alone

Execute the command make at top level.

The TSDuck binaries, executables and shared objects (.so or .dylib), are built in directory bin/release-<arch>-<hostname> by default. Consequently, the same work area can be simultaneously used by several systems. Each system builds in its own area. You can also override the build directory using make BINDIR=....

Note that TSDuck contains thousands of source files and building it can take time. However, since most machines have multiple CPU's, all makefiles are designed for parallel builds. On a quad-core machine, for instance, the command make -j10 is recommended (10 parallel compilations), reducing the total build time to a few minutes.

To cleanup the repository tree and return to a pristine source state, execute make clean at the top level.

Building without specialized dependencies

In specific configurations, you may want to disable some external libraries such as libcurl or pcsc-lite. Of course, the corresponding features in TSDuck will be disabled but the impact is limited. For instance, disabling libcurl will disable the input plugins http and hls.

The following make variables can be defined:

  • NOTEST : Do not build unitary tests.
  • NODEKTEC : No Dektec device support, remove dependency to DTAPI.
  • NOHIDES : No HiDes device support.
  • NOVATEK : No Vatek device support (modulators based on Vatek chips).
  • NOCURL : No HTTP support, remove dependency to libcurl.
  • NOPCSC : No smartcard support, remove dependency to pcsc-lite.
  • NOEDITLINE : No interactive line editing, remove dependency to libedit.
  • NOSRT : No SRT support (Secure Reliable Transport), remove dependency to libsrt.
  • NORIST : No RIST support (Reliable Internet Stream Transport), remove dependency to librist.
  • NOHWACCEL : Disable hardware acceleration such as crypto instructions.
  • ASSERTIONS : Keep assertions in production mode (slower code).

The following command, for instance, builds TSDuck without dependency to pcsc-lite, libcurl and Dektec DTAPI:

make NOPCSC=1 NOCURL=1 NODEKTEC=1

Building with RIST support on Linux

By default, TSDuck is built with RIST support on macOS, FreeBSD, DragonFlyBSD and Windows.

As of this writing, RIST (Reliable Internet Stream Transport) is not available in the standard repositories of most Linux distros. Currently, only Ubuntu 22.10, Debian 12 and Alpine Linux 3.16 support RIST. On other distros, to rebuild TSDuck with RIST support, you must either manually rebuild and install librist or get pre-built packages for various Linux distros here. If you use other versions of rpm-based or deb-based distros, the rist-installer project contains scripts to rebuild these packages.

Once the RIST library is installed (with its development package), rebuilding TSDuck automatically includes RIST support.

Building with specific debug capabilities

The following additional make variables can be defined to enable specific debug capabilities:

  • DEBUG : Compile with debug information and no optimization.
  • GPROF : Compile with code profiling using gprof.
  • GCOV : Compile with code coverage using gcov.
  • ASAN : Compile with code sanitizing using AddressSanitizer with default optimization.
  • UBSAN : Compile with code sanitizing using UndefinedBehaviorSanitizer with default optimization.

Building the TSDuck installation packages

Execute the command make installer at top level to build all packages.

Depending on the platform, the packages can be .deb or .rpm files. There is currently no support to build an installation package on other Linux distros and BSD systems.

There is no need to build the TSDuck binaries before building the installers. Building the binaries, when necessary, is part of the installer build.

All installation packages are dropped into the subdirectory pkg/installers. The packages are not deleted by the cleanup procedures. They are not pushed into the git repository either.

Special note on macOS : There is no binary package for TSDuck on macOS. On this platform, TSDuck is installed using Homebrew, a package manager for open-source projects on macOS. See here for more details.

For packagers of Linux distros

Packagers of Linux distros may want to create TSDuck packages. The build methods are not different. This section contains a few hints to help the packaging.

By default, TSDuck is built with capabilities to check the availability of new versions on GitHub. The tsversion command can also download and upgrade TSDuck from the binaries on GitHub. Packagers of Linux distros may want to disable this since they prefer to avoid mixing their TSDuck packages with the generic TSDuck packages on GitHub. To disable this feature, build TSDuck with make NOGITHUB=1.

The way to build a package depends on the package management system. Usually, the build procedure includes an installation on a temporary fake system root. To build TSDuck and install it on /temporary/fake/root, use the following command:

make NOGITHUB=1 install SYSROOT=/temporary/fake/root

It is recommended to create two distinct packages: one for the TSDuck tools and plugins and one for the development environment. The development package shall require the pre-installation of the tools package.

If you need to separately build TSDuck for each package, use targets install-tools and install-devel instead of install which installs everything:

make NOGITHUB=1 install-tools SYSROOT=/temporary/fake/root
make NOGITHUB=1 install-devel SYSROOT=/temporary/fake/root

Installing in non-standard locations

On systems where you have no administration privilege and consequently no right to use the standard installers, you may want to manually install TSDuck is some arbitrary directory.

You have to rebuild TSDuck from the source repository and install it using a command like this one:

make install SYSPREFIX=$HOME/usr/local

The TSDuck commands are located in the bin subdirectory and can be executed from here without any additional setup. It is probably a good idea to add this bin directory in your PATH environment variable.

Using pkgconfig after installation

Applications may use the pkgconfig utility to reference the TSDuck library. A file named tsduck.pc is installed in the appropriate directory.

However, pkgconfig has its own limitations, specifically regarding the configured compilation options.

TSDuck is a C++ library which requires a minimum revision of the language. Currently, the minimum revision is C++17. All more recent revisions are supported. By default, most C++ compilers are based on older revisions. Therefore, compiling an application using TSDuck with the default options fails. At least, -std=c++17 is required. To avoid compilation problems with most applications, -std=c++17 is enforced in tsduck.pc.

However, some applications may need to explicitly specify a more recent revision, such as -std=c++14 or -std=c++20, which conflicts with -std=c++17 in tsduck.pc.

For that use case, you may install TSDuck without reference to the C++ revision using the following command:

make install NOPCSTD=1

The counterpart is that the applications must specify a -std option and the revision must be C++17 or more recent.

A generic solution would be that each library and the application all provide a minimum revision of the C++ language and pkgconfig would provide a synthetic -std option which fulfills all requirements. However, this feature does not exist in pkgconfig, hence this trick.

Running from the build location

It is sometimes useful to run a TSDuck binary, tsp or any other, directly from the build directory, right after compilation. This can be required for testing or debugging.

Because the binary directory name contains the host name, it is possible to build TSDuck using the same shared source tree from various systems or virtual machines. All builds will coexist using distinct names under the bin subdirectory.

For bash users who wish to include the binary directory in the PATH, simply "source" the script scripts/setenv.sh. Example:

$ . scripts/setenv.sh
$ which tsp
/Users/devel/tsduck/bin/release-x86_64-mymac/tsp

This script can also be used with option --display to display the actual path of the binary directory. The output can be used in other scripts (including from any other shell than bash). Example:

$ scripts/setenv.sh --display
/Users/devel/tsduck/bin/release-x86_64-mymac

Use scripts/setenv.sh --help for other options.

Windows systems

Pre-requisites

Operations in this section must be run once, before building TSDuck for the first time one a given system. It should also be run to get up-to-date versions of the build tools and libraries which are used by TSDuck.

First, install Visual Studio Community Edition. This is the free version of Visual Studio. It can be downloaded here. If you already have Visual Studio Enterprise Edition (the commercial version), it is fine, no need to install the Community Edition.

Then, execute the PowerShell script scripts\install-prerequisites.ps1. It downloads and installs the requested packages which are necessary to build TSDuck on Windows.

If you prefer to collect the various installers yourself, follow the links to NSIS downloads, Git downloads, Git LFS downloads, SRT downloads, RIST downloads, Dektec downloads, Vatek downloads, Java downloads, Python downloads, Doxygen downloads and Graphviz downloads.

TSDuck now requires a C++17 compliant compiler. C++17 support started with Visual Studio 2017 15.8. We recommend to use Visual Studio 2022.

Building the binaries without installer

Execute the PowerShell script scripts\build.ps1. The TSDuck binaries, executables and DLL's, are built in directories named bin\<target>-<platform>, for instance bin\Release-x64 or bin\Debug-Win32.

To cleanup the repository tree and return to a pristine source state, execute the PowerShell script scripts\cleanup.ps1.

Building the installers

Execute the PowerShell script pkg\nsis\build-installer.ps1. By default, only the 64-bit installer is built. To build the two installers, for 32-bit and 64-bit systems, run the build script from a PowerShell window and add the option -Win32.

There is no need to build the TSDuck binaries before building the installers. Building the binaries, is part of the installer build.

All installation packages are dropped into the subdirectory pkg/installers. The packages are not deleted by the cleanup procedures. They are not pushed into the git repository either.

Installing in non-standard locations

On systems where you have no administration privilege and consequently no right to use the standard installers, you may want to manually install TSDuck is some arbitrary directory.

On Windows systems, a so-called portable package is built with the installers. This is a zip archive file which can be expanded anywhere.

Running from the build location

It is sometimes useful to run a TSDuck binary, tsp or any other, directly from the build directory, right after compilation. This can be required for testing or debugging.

The commands can be run using their complete path without additional setup. For instance, to run the released 64-bit version of tsp, use:

D:\tsduck> bin\Release-x64\tsp.exe --version
tsp: TSDuck - The MPEG Transport Stream Toolkit - version 3.12-730

For other combinations (release vs. debug and 32 vs. 64 bits), the paths from the repository root are:

bin\Release-x64\tsp.exe
bin\Release-Win32\tsp.exe
bin\Debug-x64\tsp.exe
bin\Debug-Win32\tsp.exe

Installer files summary

The following table summarizes the packages which are built and dropped into the pkg/installers directory, through a few examples, assuming that the current version of TSDuck is 3.12-745.

File name Description
tsduck_3.12-745_amd64.deb Binary package for 64-bit Ubuntu
tsduck_3.12-745_armhf.deb Binary package for 32-bit Raspbian (Raspberry Pi)
tsduck-3.12-745.el7.x86_64.rpm Binary package for 64-bit Red Hat 7.x and clones
tsduck-3.12-745.el7.src.rpm Source package for Red Hat 7.x and clones
tsduck-3.12-745.fc25.x86_64.rpm Binary package for 64-bit Fedora 25
tsduck-3.12-745.fc25.src.rpm Source package for Fedora 25
tsduck-dev_3.12-745_amd64.deb Development package for 64-bit Ubuntu
tsduck-dev_3.12-745_armhf.deb Development package for 32-bit Raspbian (Raspberry Pi)
tsduck-devel-3.12-745.el7.x86_64.rpm Development package for 64-bit Red Hat 7.x and clones
tsduck-devel-3.12-745.fc25.x86_64.rpm Development package for 64-bit Fedora 25
TSDuck-Win32-3.12-745.exe Binary installer for 32-bit Windows
TSDuck-Win64-3.12-745.exe Binary installer for 64-bit Windows
TSDuck-Win32-3.12-745-Portable.zip Portable package for 32-bit Windows
TSDuck-Win64-3.12-745-Portable.zip Portable package for 64-bit Windows

On Linux systems, there are two different packages. The package tsduck contains the tools and plugins. This is the only required package if you just need to use TSDuck. The package named tsduck-devel (Red Hat family) or tsduck-dev (Debian family) contains the development environment. It is useful only for third-party applications which use the TSDuck library.

On Windows systems, there is only one binary installer which contains the tools, plugins, documentation and development environment. The user can select which components shall be installed. The development environment is unselected by default.

On macOS systems, the Homebrew package tsduck installs all components.