This section provides information about the libqrtr-glib
library.
This the multi-page printable view of this section. Click here to print.
libqrtr-glib
- 1: API reference
- 2: Dependencies
- 3: Building
1 - API reference
The libqrtr-glib
API reference provides a detailed list of operations that may be performed with QRTR nodes.
Online references
The most up to date API reference of the libqrtr-glib
library is kept in the following location:
The full list of API references published is kept for future reference:
There is no API reference published for stable release updates that didn’t have any API change.
Local reference
The API reference is usually installed along with the libqrtr-glib
library (sometimes as a separate distribution package) under /usr/share/gtk-doc/html/libqrtr-glib/
and can be browsed locally via the Devhelp tool. The version of the installed reference will be the one applying to the libqrtr-glib
library installed in the system.
2 - Dependencies
Common dependencies
Before you can compile the libqrtr-glib library, you will need at least the following tools:
- A compliant C toolchain: e.g.
glibc
ormusl libc
,gcc
orclang/llvm
. - pkg-config, a tool for tracking the compilation flags needed for libraries.
- The glib2 library.
- For libqrtr-glib >= 1.2, glib2 >= 2.56.
- For libqrtr-glib >= 1.0, glib2 >= 2.48
In addition to the previous mandatory requirements, the project also has several optional dependencies that would be needed when enabling additional project features:
- gtk-doc tools, in order to regenerate the documentation.
- gobject-introspection, in order to generate the introspection support.
When building from a git checkout instead of from a source tarball, the following additional dependencies are required:
- GNU autotools (autoconf/automake/libtool).
- Autoconf archive
Dependencies when building libqrtr-glib 1.2 or later with meson
When building with meson, the following additional dependencies are required:
Dependencies when building libqrtr-glib 1.0 with GNU autotools
When building with the GNU autotools, the following additional dependencies are required:
There are two main ways to build the library using GNU autotools: from a git repository checkout and from a source release tarball. When building from a git checkout instead of from a source tarball, the following additional dependencies are required:
- GNU autotools (autoconf/automake/libtool).
- Autoconf archive.
3 - Building
This section provides information about how to build and install the libqrtr-glib
library.
3.1 - Building libqrtr-glib 1.2 or later with Meson
The first stable series with support for building with the meson suite is 1.2. All the older stable series before 1.2 exclusively used the GNU autotools build system.
Building from a git checkout
When using meson, the builds are always triggered from git checkouts, there is no source release tarball involved. The basic build steps would be as follows:
$ git clone --depth 1 https://gitlab.freedesktop.org/mobile-broadband/libqrtr-glib.git
$ cd libqrtr-glib
$ meson setup build --prefix=/usr
$ ninja -C build
Optional switches
Additional optional switches that may be given to the meson
command above would be:
- In Debian/Ubuntu systems the default location for libraries depends on the architecture of the build, so instead of the default
/usr/lib
path that would be in effect due to--prefix=/usr
, the user should also give an explicit--libdir
path pointing to the correct location. E.g. on a 64bit Ubuntu/Debian build, the user would use--prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu
. - The gtk-doc documentation is disabled by default. In order to enable it, the additional
-Dgtk_doc=true
switch should be given. - The GObject introspection support is enabled by default. In order to disable it, the additional
-Dintrospection=false
switch should be given. - The default build type in meson if none explicitly specified is
debug
, which means debug symbols are included and optimization is fully disabled. The--buildtype=release
switch can be used to remove debug symbols and to enable optimization level to the maximum.
An example project build using all the above optional switches could be:
$ meson setup build \
--prefix=/usr \
--libdir=/usr/lib/x86_64-linux-gnu \
--buildtype=release \
-Dgtk_doc=true \
-Dintrospection=false
$ ninja -C build
Installing
The installation on the prefix selected during meson setup
can be done with the following command:
$ sudo ninja -C build install
Please note that the command above will install the library in the system default path for libraries, possibly overwriting any previous libqrtr-glib library that may already exist from a package manager installed package. See the FAQ section for comments on how to install in /usr/local
instead.
Uninstalling
If you have manually installed the project with the steps above, it can be uninstalled in the same way:
$ sudo ninja -C build uninstall
If the manual install overwrote the package manager installed files, it is suggested to force a re-install of the corresponding packages at this point, so that the system is not left with missing files.
3.2 - Building libqrtr-glib 1.0 using GNU autotools
The last stable series with support for building with the GNU autotools suite is 1.0. All the new stable series after 1.0 will exclusively use the meson build system.
Building from a release source tarball
The basic build and installation of the project can be done from an official release source tarball, in the following way:
$ wget https://www.freedesktop.org/software/libqrtr-glib/libqrtr-glib-1.0.0.tar.xz
$ tar -Jxvf libqrtr-glib-1.0.0.tar.xz
$ cd libqrtr-glib-1.0.0
$ ./configure --prefix=/usr
$ make
Optional switches
Additional optional switches that may be given to the configure
command above would be:
- In Debian/Ubuntu systems the default location for libraries depends on the architecture of the build, so instead of the default
/usr/lib
path that would be in effect due to--prefix=/usr
, the user should also give an explicit--libdir
path pointing to the correct location. E.g. on a 64bit Ubuntu/Debian build, the user would use--prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu
. - If the documentation should be rebuilt, the additional
--enable-gtk-doc
switch should be given. Omitting this switch will imply auto-detecting whether the documentation can be rebuilt with the already installed dependencies. - If the introspection support should be included in the build, the additional
--enable-introspection
switch should be given. Omitting this switch will imply auto-detecting whether the introspection can be built with the already installed dependencies. - When developing changes to the library or debugging issues, it is recommended to build with debug symbols so that running the program under
gdb
produces useful backtrace information. This can be achieved by providing user compiler flags like these:CFLAGS="-ggdb -O0"
An example project build using all the above optional switches could be:
$ ./configure \
--prefix=/usr \
--libdir=/usr/lib/x86_64-linux-gnu \
--enable-gtk-doc \
--enable-introspection \
CFLAGS="-ggdb -O0"
$ make
Running ./configure --help
will show all the possible switches that are supported.
Building from a git checkout
When building from a git checkout, there is one single additional step required to build the project: running the included autogen.sh
in order to setup the GNU autotools project and generate a configure
script:
$ git clone https://gitlab.freedesktop.org/mobile-broadband/libqrtr-glib.git
$ cd libqrtr-glib
$ NOCONFIGURE=1 ./autogen.sh
$ ./configure --prefix=/usr
$ make
The same optional switches may be given to the configure
script when building from a git checkout.
Installing
The installation on the prefix selected during configure
can be done with the following command:
$ sudo make install
Please note that the command above will install the library in the system default path for libraries, possibly overwriting any previous libqrtr-glib library that may already exist from a package manager installed package. See the FAQ section for comments on how to install in /usr/local
instead.
Uninstalling
If you have manually installed the project with the steps above, it can be uninstalled in the same way:
$ sudo make uninstall
If the manual install overwrote the package manager installed files, it is suggested to force a re-install of the corresponding packages at this point, so that the system is not left with missing files.