We're hiring!
*

Cross-compiling with gst-build and GStreamer

Stéphane Cerveau avatar

Stéphane Cerveau
May 15, 2020

Share this post:

Reading time:

Note: In September 2021, the GStreamer project merged all its git repositories into a single, unified repository, often called monorepo. The build system referred in this post as "gst-build" is now in the root of this combined/mono repository.

gst-build is one of the main build systems used by the community to develop the GStreamer platform. In my last blog post, I presented gst-build and explained how to get started with it. Now, let's get straight to the point regarding cross-compilation.

For this example, we will target an AArch64 CPU for a Xilinx reference board, the Zynq UltraScale+ MPSoC ZCU106 Evaluation Kit. As you'll see, cross compiling can be very useful when you want to save time when working with GStreamer, or when you want to be able to work on both the host and target with the same base code.

Prerequisites

  • Toolchain (aarch64-linux-gnu-gcc) + sysroot (optional)
  • Meson cross file
  • Meson > 0.54.1

First we'll need here to have a proper toolchain to cross-build. In my case I used the regular toolchain provided by Ubuntu installing the packages:

$ sudo apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu libc6-dev-arm64-cross

This is installing a minimal toolchain in /usr/aarch64-linux-gnu/

Cross file generated with generate-cross-file.py

Below the cross file used to build for aarch64, this file has been generated with this helper script allowing to generated the cross file for other target as well. As you can see, here, we don't use a dedicated rootfs because gst-build will build all that we need for the GStreamer essentials (including libffi, glib etc.).

$ ./generate-cross-file.py
[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'arm64'
endian = 'little'

[properties]
c_args = []
cpp_args = []
objc_args = []
objcpp_args = []
c_link_args = []
cpp_link_args = []
objc_link_args = []
objcpp_link_args = []
pkg_config_libdir = ['__unknown_sysroot__']


[binaries]
c = ['aarch64-linux-gnu-gcc']
cpp = ['aarch64-linux-gnu-g++']
ar = ['aarch64-linux-gnu-ar']
pkgconfig = 'pkg-config'
strip = ['aarch64-linux-gnu-strip']

Here Meson will use aarch64-linux-gnu-gxx to compile with the given arguments setup above. As Meson does not recommend to use environment variables, the cross file contains hard-coded path to the sysroot to provide package config. Indeed since Meson > 0.54, you can define pkg_config_libdir which will help pkg-config to search for the package configuration files for the given target. You can also tell the path to the pkg-config wrapper by modifying the pkgconfig variables as well. Predefined cross file can also be found in gst-build/data/cross-files

Configuring the project for Zynq UltraScale+ MPSoC ZCU106 Evaluation Board

When the cross file ready, we can now configure gst-build in order to have a dedicated build for our platform. Here I'm disabling some unnecessary options of gst-build such as libav, vaapi or gtk_doc.

⚠ Note: Make sure that you are running Meson 0.54.1 which has the necessary patch for complete support of cross-compilation, otherwise gst-build will take glib from the system (pkg_config_libdir prerequisite).

Notice that on this platform, we use gst-omx, so we also give some options specific to this platform, in particular the path to the Xilinx OpenMAX headers .

$ /path/to/meson_0_54 build-cross-arm64 --cross-file=my-meson-cross-file.txt -D omx=enabled -D sharp=disabled -D gst-omx:header_path=/opt/allegro-vcu-omx-il/omx_header -D gst-omx:target=zynqultrascaleplus -D libav=disabled -D rtsp_server=disabled -D vaapi=disabled -D disable_gst_omx=false -Dugly=disabled -Dgtk_doc=disabled -Dglib:libmount=disabled -Dintrospection=disabled

After this step, you should be able to build with ninja.

$ ninja -C build-cross-arm64

Installing

Last but not the least, you need to install the artifacts in a folder to deploy on the device, for example, by mounting it on your target with NFS. You have to provide a DESTDIR variable to ninja and it will install in $DESTDIR/usr/local/ as install prefix.

$ DESTDIR=/opt/gst-build-cross-artifacts/linux_arm64 ninja -C build-cross-arm64 install

Running the binaries on target

After mounting the folder or copying it to your target, you have to set up a few variables to be able to run GStreamer pipelines:

    PATH=$DESTDIR/usr/local/bin:$PATH
    LD_LIBRARY_PATH=$DESTDIR/usr/local/lib:$LD_LIBRARY_PATH
    GST_PLUGIN_PATH=$DESTDIR/usr/local/lib/gstreamer-1.0
    GST_OMX_CONFIG_DIR=$DESTDIR/usr/local/etc/xdg

A python script as shell script is also available to setup the correct environment variables for your target.

$ /path_to/cross-gst-uninstalled.py /opt/gst-build-cross-artifacts/linux_arm64

Building wavpack in gst-plugins-good

To build a plugin such as wavpack which depends on the 3rd party wavpack library. You'll need to get a proper sysroot with this new library and its dependencies (if needed).

Regarding a root file-system with wavpack, I generated one with cerbero where cross compiling could be described in a next blog post :) But you should normally have it as part of your sysroot.

$ cd /opt
$ git clone https://gitlab.freedesktop.org/gstreamer/cerbero
$ cd cerbero
$ ./cerbero-uninstalled -c config/cross-lin-arm64.cbc bootstrap
$ ./cerbero-uninstalled -c config/cross-lin-arm64.cbc build wavpack

This should have generated a minimal root file-system in /opt/cerbero/build/dist/linux_arm64 which can used then with gst-build as a base root file-system.

You can now generate a new cross file with the given root file-system as parameter.

$ ./generate-cross-file.py --sysroot /opt/cerbero/build/dist/linux_arm64/ --no-include-sysroot

Here I define a sysroot to be be used but I'm disabling the use of sys_root in the cross file to avoid Meson to tell pkg-config to prefix every path with this value. cerbero is generating pkg-config files with the sysroot path already in each pc files.

[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'arm64'
endian = 'little'

[properties]
c_args = []
cpp_args = []
objc_args = []
objcpp_args = []
c_link_args = ['-L/opt/cerbero/build/dist/linux_arm64', '-Wl,-rpath-link=/opt/cerbero/build/dist/linux_arm64']
cpp_link_args = ['-L/opt/cerbero/build/dist/linux_arm64', '-Wl,-rpath-link=/opt/cerbero/build/dist/linux_arm64']
objc_link_args = ['-L/opt/cerbero/build/dist/linux_arm64', '-Wl,-rpath-link=/opt/cerbero/build/dist/linux_arm64']
objcpp_link_args = ['-L/opt/cerbero/build/dist/linux_arm64', '-Wl,-rpath-link=/opt/cerbero/build/dist/linux_arm64']
pkg_config_libdir = ['/opt/cerbero/build/dist/linux_arm64/pkgconfig:/opt/NFS/cerbero_rootfs/linux_arm64//usr/share/pkgconfig']


[binaries]
c = ['aarch64-linux-gnu-gcc']
cpp = ['aarch64-linux-gnu-g++']
ar = ['aarch64-linux-gnu-ar']
pkgconfig = 'pkg-config'
strip = ['aarch64-linux-gnu-strip']

Now you should be able to go back to the configure/build/install step and get the wavpack in your plugins registry.

I hope you'll enjoy the use of gst-build, which is for me a very powerful and flexible tool. A lot of options can be found in the gst-build README such as the update or the use of GStreamer branches.

If you would like to learn more about gst-build or any other parts of GStreamer, please contact us!

Comments (6)

  1. Stephane:
    Sep 20, 2021 at 01:19 PM

    Depending on the host and the target, the libc might be incompatible for glib and gstreamer, so better to provide a sys root according to your target or find the right combination if you install the compiler with a given package manager.

    Reply to this comment

    Reply to this comment

  2. Howard Harvey:
    Oct 25, 2022 at 07:13 PM

    I am attempting to re-create your little Xilinx cross compile for zcu106, and have encountered a rather odd
    build error:

    Library dl found: YES
    Checking for function "dladdr" with dependency -ldl: YES
    Run-time dependency glib-2.0 found: NO (tried pkgconfig and cmake)
    Looking for a fallback subproject for the dependency glib-2.0

    meson.build:482:0: ERROR: Neither a subproject directory nor a glib.wrap file was found.

    Exceptionally puzzling, since this is on a machine where the native x64 build comes together just fine....

    Was wondering if this is something you had encountered.....

    Reply to this comment

    Reply to this comment

    1. Xavier Claessens:
      Oct 25, 2022 at 07:32 PM

      You need to cross compile glib too, Meson is not going to use the one from your system. You should have the file gst-build/subprojects/glib.wrap to tell Meson how to cross compile GLib, are you missing that file?

      Reply to this comment

      Reply to this comment

      1. Howard Harvey:
        Oct 25, 2022 at 07:48 PM

        Well, I'm not actually 'missing' glib.wrap...... It is in gst-build/subprojects/glib.wrap, but I suspect that I
        need to install/copy it somewhere so that the meson build process cane use it? However, I did
        find that if I copy it via
        cp ./subprojects/glib.wrap ./subprojects/glib/subprojects
        that the build gets past the glib build process

        Many thanks!

        Reply to this comment

        Reply to this comment

        1. Xavier Claessens:
          Oct 25, 2022 at 07:59 PM

          subprojects/glib.wrap should be the correct location, I'm not sure what you're doing... You could try with a more recent Meson and with GStreamer >= 1.18, gst-build is old and not used any more.

          Reply to this comment

          Reply to this comment

  3. Howard Harvey:
    Oct 26, 2022 at 09:23 PM

    Quite right you are. Once I moved to latest-and-greatest of gstreamer, rather than the explicit 1.18 branch build, things got a whole heck of a lot easier. Many thanks for having a look at my problem and the resultant guidance.

    Reply to this comment

    Reply to this comment


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

Automatic regression handling and reporting for the Linux Kernel

14/03/2024

In continuation with our series about Kernel Integration we'll go into more detail about how regression detection, processing, and tracking…

Almost a fully open-source boot chain for Rockchip's RK3588!

21/02/2024

Now included in our Debian images & available via our GitLab, you can build a complete, working BL31 (Boot Loader stage 3.1), and replace…

What's the latest with WirePlumber?

19/02/2024

Back in 2022, after a series of issues were found in its design, I made the call to rework some of WirePlumber's fundamentals in order to…

DRM-CI: A GitLab-CI pipeline for Linux kernel testing

08/02/2024

Continuing our Kernel Integration series, we're excited to introduce DRM-CI, a groundbreaking solution that enables developers to test their…

Persian Rug, Part 4 - The limitations of proxies

23/01/2024

This is the fourth and final part in a series on persian-rug, a Rust crate for interconnected objects. We've touched on the two big limitations:…

How to share code between Vulkan and Gallium

16/01/2024

One of the key high-level challenges of building Mesa drivers these days is figuring out how to best share code between a Vulkan driver…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2024. All rights reserved. Privacy Notice. Sitemap.