How compile and run time dependencies for packages are managed in yocto / bitbake recipes ?

Dependencies

Most software packages have a short list of other packages that they require, which are called dependencies. These dependencies fall into two main categories: build-time dependencies, which are required when the software is built; and runtime dependencies, which are required to be installed on the target in order for the software to run.

Within a recipe, you specify build-time dependencies using the DEPENDS variable. Although nuances exist, items specified in DEPENDS should be names of other recipes. It is important that you specify all build-time dependencies explicitly. If you do not, due to the parallel nature of BitBake’s execution, you can end up with a race condition where the dependency is present for one task of a recipe (e.g. do_configure) and then gone when the next task runs (e.g. do_compile).

Another consideration is that configure scripts might automatically check for optional dependencies and enable corresponding functionality if those dependencies are found. This behavior means that to ensure deterministic results and thus avoid more race conditions, you need to either explicitly specify these dependencies as well, or tell the configure script explicitly to disable the functionality. If you wish to make a recipe that is more generally useful (e.g. publish the recipe in a layer for others to use), instead of hard-disabling the functionality, you can use the PACKAGECONFIG variable to allow functionality and the corresponding dependencies to be enabled and disabled easily by other users of the recipe.

Similar to build-time dependencies, you specify runtime dependencies through a variable – RDEPENDS, which is package-specific. All variables that are package-specific need to have the name of the package added to the end as an override. Since the main package for a recipe has the same name as the recipe, and the recipe’s name can be found through the ${PN} variable, then you specify the dependencies for the main package by setting RDEPENDS_${PN}. If the package were named ${PN}-tools, then you would set RDEPENDS_${PN}-tools, and so forth.

Some runtime dependencies will be set automatically at packaging time. These dependencies include any shared library dependencies (i.e. if a package “example” contains “libexample” and another package “mypackage” contains a binary that links to “libexample” then the OpenEmbedded build system will automatically add a runtime dependency to “mypackage” on “example”).

21.4. Automatically Added Runtime Dependencies

The OpenEmbedded build system automatically adds common types of runtime dependencies between packages, which means that you do not need to explicitly declare the packages using RDEPENDS. Three automatic mechanisms exist (shlibdeps, pcdeps, and depchains) that handle shared libraries, package configuration (pkg-config) modules, and -dev and -dbg packages, respectively. For other types of runtime dependencies, you must manually declare the dependencies.

  • shlibdeps: During the do_package task of each recipe, all shared libraries installed by the recipe are located. For each shared library, the package that contains the shared library is registered as providing the shared library. More specifically, the package is registered as providing the soname of the library. The resulting shared-library-to-package mapping is saved globally in PKGDATA_DIR by the do_packagedata task.Simultaneously, all executables and shared libraries installed by the recipe are inspected to see what shared libraries they link against. For each shared library dependency that is found, PKGDATA_DIR is queried to see if some package (likely from a different recipe) contains the shared library. If such a package is found, a runtime dependency is added from the package that depends on the shared library to the package that contains the library.

    The automatically added runtime dependency also includes a version restriction. This version restriction specifies that at least the current version of the package that provides the shared library must be used, as if “package (>= version)” had been added to RDEPENDS. This forces an upgrade of the package containing the shared library when installing the package that depends on the library, if needed.

    If you want to avoid a package being registered as providing a particular shared library (e.g. because the library is for internal use only), then add the library to PRIVATE_LIBS inside the package’s recipe.

  • pcdeps: During the do_package task of each recipe, all pkg-config modules (*.pc files) installed by the recipe are located. For each module, the package that contains the module is registered as providing the module. The resulting module-to-package mapping is saved globally in PKGDATA_DIR by the do_packagedata task.Simultaneously, all pkg-config modules installed by the recipe are inspected to see what other pkg-config modules they depend on. A module is seen as depending on another module if it contains a “Requires:” line that specifies the other module. For each module dependency, PKGDATA_DIR is queried to see if some package contains the module. If such a package is found, a runtime dependency is added from the package that depends on the module to the package that contains the module.

    Note

    The pcdeps mechanism most often infers dependencies between -dev packages.

  • depchains: If a package foo depends on a package bar, then foo-dev and foo-dbg are also made to depend on bar-dev and bar-dbg, respectively. Taking the -dev packages as an example, the bar-dev package might provide headers and shared library symlinks needed by foo-dev, which shows the need for a dependency between the packages.The dependencies added by depchains are in the form of RRECOMMENDS.

    Note

    By default, foo-dev also has an RDEPENDS-style dependency on foo, because the default value of RDEPENDS_${PN}-dev (set in bitbake.conf) includes “${PN}”.

    To ensure that the dependency chain is never broken, -dev and -dbg packages are always generated by default, even if the packages turn out to be empty. See the ALLOW_EMPTY variable for more information.

The do_package task depends on the do_packagedata task of each recipe in DEPENDS through use of a [deptask] declaration, which guarantees that the required shared-library/module-to-package mapping information will be available when needed as long as DEPENDS has been correctly set.

Reference – http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html 

http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#automatically-added-runtime-dependencies

READ  Creating a New BSP Layer Using the yocto-bsp Script

Leave a Reply

Your email address will not be published. Required fields are marked *