Embedded Linux using Yocto Part 3

Learn what a static library is and how it serves as an archive of object files with a .a extension. Use the ar tool to create it from object files.

Demonstrates creating object files, archiving into a static library with ar, and linking from an application with non-standard include paths and Yocto recipe integration.

Create a static library recipe in Yocto, define sources, build object files, output lib to usr lib and header to include dir, and manage empty packages with allow_empty.

Create dynamic libraries by generating position independent code with -fpic and building the library with -shared and a surname, ensuring symbolic links point to the real file for runtime linking.

Understand dynamic library naming in Linux, including linker name, soname, and real name with lib prefixes and versioning. Installation creates symlinks linking linker and soname to the real library.

Create a dynamic library recipe in your meta layer, copy files, and install into lib with symbolic links; headers appear only for static libraries, and unversioned links are development-time only.

Packaging unversioned libraries requires adjusting files and packages variables to place the library in the main package, not the development package, to avoid non symbolic link errors in BitBake.

Challenge session: write a Yocto recipe that builds a C program using a shared library, exercising library functions such as print and arithmetic like add, subtract, and extract.

Learn about build time and runtime dependencies in Yocto, and how the depends and rdepends variables govern recipe builds and package installations.

Declare build time dependencies with the depends variable and order recipes. Examine the do populate root task that copies files from do install into the root to prepare the image.

Learn how Yocto shares files between recipes by exposing library files and headers through per-machine routes, enabling applications to access host and target library resources.

update the my hello recipe to use the static library and declare a build-time dependency on my static. bitbake builds the dependency first and compiles the hello with proper includes.

Update the myhello recipe to depend on a versioned dynamic library, compare static versus dynamic dependencies, clean the project, build the dynamic, and verify the recipe labels.

Learn how runtime dependencies are declared with the depends variable in Yocto, contrasted with build-time depends, and how BitBake uses rdepends and the do package write task.

Write a C program that calls lspci as a system call, declare runtime dependencies with depends and override syntax, and ensure lspci is included in the rootfs via PCI utils.

Lock a package to a specific version of another recipe using operators like =, <, <=, >, and >=, as in depending on 0.2 when multiple recipes exist.

Generate a recipe dependency view with bitbake -g, producing a build list and a task dependency dot file; view with dot to understand why a recipe builds.

Learn the dot format to describe graphics and generate directed graphs, convert dot files to pdf, and use bitbake's dependency explorer to view build-time and runtime recipe dependencies.

Use the bitbake noexec flag to mark tasks as empty and prevent execution, enabling you to skip patch and configure steps when a custom Makefile handles build tasks.

Makefiles generate executables from source code and speed builds by skipping unchanged files, but portability across platforms remains challenging; autotools or cmake address this.

Autotools provides Automake and Autoconf to help developers make source code portable across Unix-like systems, using configure to verify dependencies, generate a makefile.in, and run make and make install.

Learn to configure autotools by enabling the C compiler, generate makefiles with automake from Makefile.am, and build, install, and uninstall a hello world user program.

Generate a tarball using autotools make, where make dist builds a portable tarball containing the configure script, makefile.am, Makefile, and user programs for distribution on Unix-like systems.

Learn how the GNU hello world program, built with autotools, prints hello world or a custom message, and how to download, configure, compile, install, and view its man page.

Create a hello autotools recipe in Yocto by specifying the source url and license, adding checksums, and inheriting the autotools class to automate configure, compile, and install steps.

Address out-of-tree build errors by inheriting autotools-broken-shell for non-out-of-tree recipes; verify build and source directories match, then build with bitbake to achieve successful compilation and installation.

explains autotools.bbclass workflow, showing configure and extra configure options, make steps, and install into rootfs, plus writing an autotools recipe and inspecting the dbclass file.

Use extra conf to pass options to the configure script, enabling or disabling features in Yocto recipes. See how auto tools are used to craft a hello world package.

Explore cmake as a cross-platform, compiler and operating system independent build system. Compare it with autotools and see how it generates Makefiles on Linux and Visual Studio or Xcode projects.

Discover how to install CMake on Linux with distribution-specific commands for Ubuntu and Red Hat. Verify CMake is installed and install it if necessary.

Create a hello world program and its CMakeLists.txt, then generate a makefile in a separate build directory to compile an executable with cmake, or via cmake --build or make.

Builds run in a separate folder to keep the workspace clean and start fresh. Set a minimum CMake version and a project name to prevent mismatches and enable reliable builds.

Learn to add a cmake install target to build and place executables in usr bin or usr local bin, use sudo for installation, and understand install versus uninstall targets.

explain how cmake install prefix prepends to all install directories and show how to switch from /usr/local/bin to /usr/bin by updating cmake install prefix, then run make install.

Create a basic Yocto recipe for a cmake project by setting the source and inheriting the cmake class, then build and install the hello world in the image.

Use the EXTRA_OECMAKE variable to pass configuration options to recipes in Yocto, focusing on cmake-based options and installing binaries into bin while inspecting the package space.

Start a dev shell with the -C dev option to set up environment variables for building from source via recipes, run patch steps, and debug with configure and make.

Explore how Yocto's dev shell sets cross-compiling variables like CC for the target, and learn to configure and build recipes using autotools and cmake.

Changes made in the dev shell are not persistent between builds. Commit changes in a local git repo and generate a patch with git format-patch to save and apply later.

Learn how Bitbake searches for files using the files path variable, and how folder naming (package name, package version, or files folder) affects locating patches, cmake lists, and user programs.

Use files overrides to tailor per-machine configurations by extending file paths with machine-specific overrides, enabling distinct def configs and source code per target.

Extend the open embedded build system's search path with FILESEXTRAPATHS to locate files and patches using the files path, overrides, and files extra path variable.

Enable and customize the splash screen in Yocto by using p splash, a user space framebuffer boot logo, and modify the recipe to display your own logo during boot.

Replace the Yocto splash logo by converting your image to a header, updating the splash recipe in a dev shell, and rebuilding the image.

Learn how to extend a recipe in Yocto, comparing copy vs extend approaches, and using bitbake append to modify recipes without duplicating them.

Learn how bbappend lets you extend existing recipes across layers, preventing duplication and automatically applying cross-layer changes, while ensuring append files share the same root name and path conventions.

Assign priority values to layers to control precedence. Ensure the higher-priority layer's recipe file is selected when names collide, and apply the same rule to appended files.

Use bbappend to customize psplash in your own layer, not pokey. Match the folder layout, file names, and files extra paths, and set layer priority to control the splash logo.

Learn to verify recipe appends in Yocto using the show appends command. It lists append files and their target recipes and explains how layer priority determines which append applies.