> ## Content Index
> Fetch the complete content index at: https://www.smallstepsystems.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Building Yocto Packages Manually with devshell
- URL: https://www.smallstepsystems.com/building-yocto-packages-manually-with-devshell/
- Published: 2018-10-13T13:14:22.000Z
- Updated: 2026-01-25T15:46:19.000Z
- Author: Burkhard Stubert
- Tags: Embedded Linux

We must figure out why a Yocto package doesn't work as expected. So, we must tweak the source code a bit here and there, cross-build the package for our ARM-based embedded Linux system and install some shared libraries from the package on the embedded Linux system. Of course, we want short turnaround times to try out our changes quickly. The *bitbake* task *devshell* will save our day.

We use a not so hypothetical problem in the *qtmultimedia* package as our running example. Our Yocto build environment for our embedded system is fully set up. The Linux system is properly running on an i.MX6 microprocessor. Our main application is supposed to show a video stream from an IP camera, but it only shows a black rectangle. Most likely, we must change some source files of the *qtmultimedia* package.

Yocto provides a magic command to set up the proper development environment. We call  
  
`$ bitbake -c devshell qtmultimedia`  
  
in the standard Yocto build directory. This command opens a development shell, sets the environment variables to the correct values for a cross-build and changes to the root directory of the package's source tree: *.../build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/qtmultimedia/5.10.1+gitAUTOINC+038716bb1f-r0/git*. The *devshell* task even figures out the unwieldy base source directory for us.

We modify some source files in *.../git/src/plugins/gstreamer/mediaplayer*. Then, we change to the base build directory *.../5.10.1+gitAUTOINC+038716bb1f-r0/build*, which is a sibling of the base source directory. We run the command `make -j8` to cross-build the *qtmultimedia* package. This rebuilds the plugin *.../build/plugins/mediaservice/libgstmediaplayer.so*. We copy the plugin to the right place (here: */usr/lib/qt5/plugins/mediaservice/*) on the target system and rerun the main application.

If the changes don't fix the problem, we will repeat the steps above. If they fix the problem, we will create a patch from our source code changes and make the package recipe install the patch. Then, we return to building the Linux image the normal way. We run *bitbake* on the image recipe or on the package recipe.

An alternative to using *devshell* is the command  
  
`$ bitbake -C compile qtmultimedia`  
  
The command invalidates the timestamp of the task *compile*, which forces a recompilation of the package *qtmultimedia*. In contrast, the option `-c` (lowercase "c") would not trigger a recompilation, but regard the task as up-to-date.

The command also runs the tasks that depend on the task *compile*. Hence, it installs the build artefacts in the directory *.../sysroot-destdir*, which is a sibling of the base source and build directories. We can pack together the tree below *.../sysroot-destdir* and unpack it on the target system. This ensures that we don't forget to install any artefacts.

The turnaround time of the alternative solution is longer than for the *devshell* solution. However, the alternative solution makes it harder to forget any artefacts. If we don't exactly know, which files must be installed on the target system, we should prefer the alternative solution. Otherwise, we can use the *devshell* solution - especially if a fast turnaround time is important.