Working With Libraries
- Libraries are an integral part of your system.
- This section describes some common practices you might find
+ Libraries are an integral part of your system.
+ This section describes some common practices you might find
helpful when working with libraries to build your system:
How to include static library files
@@ -1442,46 +1442,46 @@
Installing Multiple Versions of the Same Library
- Situations can exist where you need to install and use
+ Situations can exist where you need to install and use
multiple versions of the same library on the same system
at the same time.
- These situations almost always exist when a library API
- changes and you have multiple pieces of software that
+ These situations almost always exist when a library API
+ changes and you have multiple pieces of software that
depend on the separate versions of the library.
- To accomodate these situations, you can install multiple
+ To accomodate these situations, you can install multiple
versions of the same library in parallel on the same system.
The process is straight forward as long as the libraries use
proper versioning.
- With properly versioned libraries, all you need to do to
+ With properly versioned libraries, all you need to do to
individually specify the libraries is create separate,
- appropriately named recipes where the
- PN part of the
+ appropriately named recipes where the
+ PN part of the
name includes a portion that differentiates each library version
(e.g.the major part of the version number).
Thus, instead of having a single recipe that loads one version
- of a library (e.g. clutter), you provide
+ of a library (e.g. clutter), you provide
multiple recipes that result in different versions
of the libraries you want.
- As an example, the following two recipes would allow the
- two separate versions of the clutter
+ As an example, the following two recipes would allow the
+ two separate versions of the clutter
library to co-exist on the same system:
clutter-1.6_1.6.20.bb
clutter-1.8_1.8.4.bb
- Additionally, if you have other recipes that depend on a given
- library, you need to use the
- DEPENDS
- variable to create the dependency.
+ Additionally, if you have other recipes that depend on a given
+ library, you need to use the
+ DEPENDS
+ variable to create the dependency.
Continuing with the same example, if you want to have a recipe
- depend on the 1.8 version of the clutter
+ depend on the 1.8 version of the clutter
library, use the following in your recipe:
DEPENDS = "clutter-1.8"
-
+
@@ -2197,9 +2197,9 @@
Very small distributions have some significant advantages such
- as requiring less on-die or in-package memory (cheaper), better
- performance through efficient cache usage, lower power requirements
- due to less memory, faster boot times, and reduced development
+ as requiring less on-die or in-package memory (cheaper), better
+ performance through efficient cache usage, lower power requirements
+ due to less memory, faster boot times, and reduced development
overhead.
Some real-world examples where a very small distribution gives
you distinct advantages are digital cameras, medical devices,
@@ -2346,7 +2346,7 @@
Trim the Root Filesystem
- The root filesystem is made up of packages for booting,
+ The root filesystem is made up of packages for booting,
libraries, and applications.
To change things you can configure how the packaging happens,
which changes the way you build them.
@@ -2366,7 +2366,7 @@
a certain size.
This example filters out anything below 100 Kbytes.
The sizes reported by the tool are uncompressed and thus,
- will be smaller by a relatively constant factor in a
+ will be smaller by a relatively constant factor in a
compressed root filesystem.
When you examine your log file, you can focus on areas of the
root filesystem that take up large amounts of memory.
@@ -2390,7 +2390,7 @@
result in minimal impact on the feature set.
For example, you might not need a VGA display.
Or, you might be able to get by with devtmpfs
- and mdev instead of
+ and mdev instead of
udev.
@@ -2406,10 +2406,10 @@
Finally, you should consider exactly the type of root
- filesystem you need to meet your needs while also reducing
+ filesystem you need to meet your needs while also reducing
its size.
- For example, consider cramfs,
- squashfs, ubifs,
+ For example, consider cramfs,
+ squashfs, ubifs,
ext2, or an initramfs
using initramfs.
Be aware that ext3 requires a 1 Mbyte
@@ -2455,7 +2455,7 @@
drivers, networking, core kernel files, filesystem, sound,
and so forth.
The sizes reported by the tool are uncompressed and thus,
- will be smaller by a relatively constant factor in a compressed
+ will be smaller by a relatively constant factor in a compressed
kernel image.
Look to reduce the areas that are large and taking up around
the "90% rule".
@@ -3074,6 +3074,61 @@
+
+ Selecting an Initialization Manager
+
+
+ By default, the Yocto Project uses
+ SysVinit as the initialization manager.
+ However, support also exists for systemd.
+ If you want to use SysVinit, you do
+ not have to do anything.
+ But, if you want to use systemd, you must
+ take some steps as described in the following sections.
+
+
+
+ Using systemd Exclusively
+
+
+ Set the following variables in your
+ local.conf file as follows:
+
+ DISTRO_FEATURES = "systemd"
+ VIRTUAL-RUNTIME_init-manager = "systemd"
+
+ You can save some disk space by adding
+ sysvinit to the distribution features
+ considered for backfill as follows:
+
+ DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
+
+ Doing so removes any redundant sysvinit
+ scripts.
+
+
+
+
+ Use systemd for the Main Image and Use SysVinit for the Rescue Image
+
+
+ Set the following variables in your
+ local.conf file as follows:
+
+ DISTRO_FEATURES = "systemd"
+ VIRTUAL-RUNTIME_init-manager = "systemd"
+
+ Doing so causes your main image to use
+ packagegroup-core-boot and
+ systemd.
+ The rescue/minimal image cannot use this group.
+ However, it can install sysvinit
+ and the appropriate packages with have both
+ systemd and sysvinit.
+
+
+
+
Excluding Recipes From the Build
@@ -3269,10 +3324,10 @@
Aside from the GDB cross-binary, you also need a GDB
- initialization file in the same top directory in which
+ initialization file in the same top directory in which
your binary resides.
When you start GDB on your host development system, GDB
- finds this initialization file and executes all the
+ finds this initialization file and executes all the
commands within.
For information on the .gdbinit, see
"Debugging with GDB"
@@ -3289,7 +3344,7 @@
the following to set your root filesystem location
by using a command with this form:
- set sysroot <your-sysroot-path>
+ set sysroot <your-sysroot-path>
@@ -3298,17 +3353,17 @@
Launch the Host GDB
- To launch the host GDB, you need to source the
+ To launch the host GDB, you need to source the
cross-debugging environment script, which if you installed
- the root filesystem in the default location is at
- /opt/poky/&DISTRO; and begins with the
+ the root filesystem in the default location is at
+ /opt/poky/&DISTRO; and begins with the
string "environment-setup".
- Finally, run the cross-gdb binary
+ Finally, run the cross-gdb binary
and provide the inferior binary as part of the command line.
- For example, the following command form continues with the
+ For example, the following command form continues with the
example used in the previous section.
This command form loads the foo binary
as well as the debugging information: