dev-manual: Review edits applied to selecting init manager section.
Applied comments based on Ross Burton's review of this new section. (From yocto-docs rev: d4f5f7b712ea2944efffec9b675341143675efb0) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
d95a27b4d9
commit
06af7c1b32
|
|
@ -411,7 +411,7 @@
|
|||
install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
|
||||
fi
|
||||
} </literallayout>
|
||||
In the main recipe, note the
|
||||
In the main recipe, note the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||||
variable, which tells the OpenEmbedded build system where to
|
||||
find files during the build.
|
||||
|
|
@ -431,27 +431,27 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
By default, the build system uses the
|
||||
By default, the build system uses the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
|
||||
variable to locate files.
|
||||
This append file extends the locations by setting the
|
||||
This append file extends the locations by setting the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||||
variable.
|
||||
Setting this variable in the <filename>.bbappend</filename>
|
||||
file is the most reliable and recommended method for adding
|
||||
directories to the search path used by the build system
|
||||
file is the most reliable and recommended method for adding
|
||||
directories to the search path used by the build system
|
||||
to find files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The statement in this example extends the directories to include
|
||||
<filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>,
|
||||
which resolves to a directory named
|
||||
<filename>formfactor</filename> in the same directory
|
||||
The statement in this example extends the directories to include
|
||||
<filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>,
|
||||
which resolves to a directory named
|
||||
<filename>formfactor</filename> in the same directory
|
||||
in which the append file resides (i.e.
|
||||
<filename>meta-intel/meta-crownbay/recipes-bsp/formfactor/formfactor</filename>.
|
||||
This implies that you must have the supporting directory
|
||||
structure set up that will contain any files or patches you
|
||||
This implies that you must have the supporting directory
|
||||
structure set up that will contain any files or patches you
|
||||
will be including from the layer.
|
||||
</para>
|
||||
|
||||
|
|
@ -660,7 +660,7 @@
|
|||
script to accept the default value.
|
||||
Once the script completes, the new layer
|
||||
is created in the current working directory.
|
||||
The script names the layer by prepending
|
||||
The script names the layer by prepending
|
||||
<filename>meta-</filename> to the name you provide.
|
||||
</para>
|
||||
|
||||
|
|
@ -1270,7 +1270,7 @@
|
|||
|
||||
<para>
|
||||
To add a post-installation script to a package, add a
|
||||
<filename>pkg_postinst_PACKAGENAME()</filename> function to the
|
||||
<filename>pkg_postinst_PACKAGENAME()</filename> function to the
|
||||
<filename>.bb</filename> file and use
|
||||
<filename>PACKAGENAME</filename> as the name of the package you want to attach to the
|
||||
<filename>postinst</filename> script.
|
||||
|
|
@ -1504,8 +1504,8 @@
|
|||
By default, the <filename>PACKAGES</filename> variable contains
|
||||
<filename>${PN}-staticdev</filename>, which includes all static library files.
|
||||
<note>
|
||||
Some previously released versions of the Yocto Project
|
||||
defined the static library files through
|
||||
Some previously released versions of the Yocto Project
|
||||
defined the static library files through
|
||||
<filename>${PN}-dev</filename>.
|
||||
</note>
|
||||
Following, is part of the BitBake configuration file.
|
||||
|
|
@ -1810,7 +1810,7 @@
|
|||
<para>
|
||||
To use the <filename>menuconfig</filename> tool in the Yocto Project development
|
||||
environment, you must build the tool using BitBake.
|
||||
Thus, the environment must be set up using the
|
||||
Thus, the environment must be set up using the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
|
||||
script found in the
|
||||
<link linkend='build-directory'>Build Directory</link>.
|
||||
|
|
@ -2240,7 +2240,7 @@
|
|||
The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||||
and <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||||
statements enable the OpenEmbedded build system to find the patch file.
|
||||
For more information on using append files, see the
|
||||
For more information on using append files, see the
|
||||
"<link linkend='using-bbappend-files'>Using .bbappend Files</link>"
|
||||
section.
|
||||
</para></listitem>
|
||||
|
|
@ -2262,7 +2262,7 @@
|
|||
<itemizedlist>
|
||||
<listitem><para><emphasis>Build for the correct target architecture:</emphasis> Your
|
||||
selected <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||||
definition within the <filename>local.conf</filename> file in the
|
||||
definition within the <filename>local.conf</filename> file in the
|
||||
<link linkend='build-directory'>Build Directory</link>
|
||||
specifies the target architecture used when building the Linux kernel.
|
||||
By default, <filename>MACHINE</filename> is set to
|
||||
|
|
@ -2270,7 +2270,7 @@
|
|||
<trademark class='registered'>Intel</trademark> Architecture
|
||||
target machine suitable for the QEMU emulator.</para></listitem>
|
||||
<listitem><para><emphasis>Identify your <filename>meta-mylayer</filename>
|
||||
layer:</emphasis> The
|
||||
layer:</emphasis> The
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
|
||||
variable in the
|
||||
<filename>bblayers.conf</filename> file found in the
|
||||
|
|
@ -2306,7 +2306,7 @@
|
|||
<orderedlist>
|
||||
<listitem><para><emphasis>Be sure your build environment is initialized</emphasis>:
|
||||
Your environment should be set up since you previously sourced
|
||||
the
|
||||
the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
|
||||
script.
|
||||
If it is not, source the script again from <filename>poky</filename>.
|
||||
|
|
@ -2322,7 +2322,7 @@
|
|||
$ bitbake -c cleansstate linux-yocto
|
||||
</literallayout></para>
|
||||
<para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
|
||||
directory inside the
|
||||
directory inside the
|
||||
<link linkend='build-directory'>Build Directory</link>.
|
||||
Always use the various BitBake clean tasks to clear out previous
|
||||
build artifacts.
|
||||
|
|
@ -2390,7 +2390,7 @@
|
|||
configurations in a <filename>local.conf</filename>
|
||||
configuration file makes it easier to reproduce the same
|
||||
build configuration when using multiple build machines.
|
||||
See the
|
||||
See the
|
||||
"<link linkend='creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</link>"
|
||||
section for information on how to quickly set up a layer.
|
||||
</para></listitem>
|
||||
|
|
@ -2416,7 +2416,7 @@
|
|||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME'><filename>DISTRO_NAME</filename></ulink> [required]
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_VERSION'><filename>DISTRO_VERSION</filename></ulink> [required]
|
||||
</literallayout>
|
||||
These following variables are optional and you typically
|
||||
These following variables are optional and you typically
|
||||
set them from the distribution configuration file:
|
||||
<literallayout class='monospaced'>
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink> [optional]
|
||||
|
|
@ -2427,7 +2427,7 @@
|
|||
<tip>
|
||||
If you want to base your distribution configuration file
|
||||
on the very basic configuration from OE-Core, you
|
||||
can use
|
||||
can use
|
||||
<filename>conf/distro/defaultsetup.conf</filename> as
|
||||
a reference and just include variables that differ
|
||||
as compared to <filename>defaultsetup.conf</filename>.
|
||||
|
|
@ -2573,7 +2573,7 @@
|
|||
<filename>poky-tiny</filename>.
|
||||
<note>
|
||||
To use <filename>poky-tiny</filename> in your build,
|
||||
set the
|
||||
set the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
|
||||
variable in your
|
||||
<filename>local.conf</filename> file to "poky-tiny"
|
||||
|
|
@ -3069,7 +3069,7 @@
|
|||
|
||||
<para>
|
||||
The alternative to setting up a PR Service is to manually
|
||||
bump the
|
||||
bump the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
|
||||
variable.
|
||||
</para>
|
||||
|
|
@ -3102,8 +3102,8 @@
|
|||
<para>
|
||||
When upgrading the version of a package, assuming the
|
||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'>PV</ulink></filename>
|
||||
changes, the <filename>PR</filename> variable should be
|
||||
reset to "r0" (or "$(INC_PR).0" if you are using
|
||||
changes, the <filename>PR</filename> variable should be
|
||||
reset to "r0" (or "$(INC_PR).0" if you are using
|
||||
<filename>INC_PR</filename>).
|
||||
</para>
|
||||
|
||||
|
|
@ -3163,7 +3163,7 @@
|
|||
$ bitbake world -f -c distro_check
|
||||
</literallayout>
|
||||
The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename>
|
||||
file found in the
|
||||
file found in the
|
||||
<link linkend='source-directory'>Source Directory</link>.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -3203,7 +3203,7 @@
|
|||
The <filename>do_split_packages</filename> function
|
||||
searches for a pattern of files or directories under a
|
||||
specified path and creates a package for each one it finds
|
||||
by appending to the
|
||||
by appending to the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
|
||||
variable and setting the appropriate values for
|
||||
<filename>FILES_packagename</filename>,
|
||||
|
|
@ -3241,7 +3241,7 @@
|
|||
Thus, if a file in <filename>${libdir}</filename>
|
||||
called <filename>mod_alias.so</filename> is found,
|
||||
a package called <filename>lighttpd-module-alias</filename>
|
||||
is created for it and the
|
||||
is created for it and the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DESCRIPTION'><filename>DESCRIPTION</filename></ulink>
|
||||
is set to "Lighttpd module for alias".</para></listitem>
|
||||
</itemizedlist>
|
||||
|
|
@ -3265,7 +3265,7 @@
|
|||
<filename>do_split_packages</filename>, see the
|
||||
<filename>connman.inc</filename> file in the
|
||||
<filename>meta/recipes-connectivity/connman/</filename>
|
||||
directory of the <filename>poky</filename>
|
||||
directory of the <filename>poky</filename>
|
||||
<link linkend='yocto-project-repositories'>source repository</link>.
|
||||
You can also find examples in
|
||||
<filename>meta/classes/kernel.bbclass</filename>.
|
||||
|
|
@ -3535,33 +3535,33 @@
|
|||
<title>Testing Packages With ptest</title>
|
||||
|
||||
<para>
|
||||
A Package Test (ptest) runs tests against packages built
|
||||
A Package Test (ptest) runs tests against packages built
|
||||
by the OpenEmbedded build system on the target machine.
|
||||
A ptest contains at least two items: the actual test, and
|
||||
A ptest contains at least two items: the actual test, and
|
||||
a shell script (<filename>run-ptest</filename>) that starts
|
||||
the test.
|
||||
The shell script that starts the test must not contain
|
||||
The shell script that starts the test must not contain
|
||||
the actual test, the script only starts it.
|
||||
On the other hand, the test can be anything from a simple
|
||||
shell script that runs a binary and checks the output to
|
||||
shell script that runs a binary and checks the output to
|
||||
an elaborate system of test binaries and data files.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The test generates output in the format used by
|
||||
The test generates output in the format used by
|
||||
Automake:
|
||||
<literallayout class='monospaced'>
|
||||
<result>: <testname>
|
||||
</literallayout>
|
||||
where the result can be <filename>PASS</filename>,
|
||||
where the result can be <filename>PASS</filename>,
|
||||
<filename>FAIL</filename>, or <filename>SKIP</filename>,
|
||||
and the testname can be any identifying string.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
With this release of the Yocto Project, three recipes exist
|
||||
that are "ptest-enabled": <filename>bash</filename>,
|
||||
<filename>glib-2.0</filename>, and
|
||||
that are "ptest-enabled": <filename>bash</filename>,
|
||||
<filename>glib-2.0</filename>, and
|
||||
<filename>dbus</filename>.
|
||||
These three recipes are Autotool-enabled.
|
||||
</note>
|
||||
|
|
@ -3570,20 +3570,20 @@
|
|||
<title>Adding ptest to Your Build</title>
|
||||
|
||||
<para>
|
||||
To add package testing to your build, add the
|
||||
To add package testing to your build, add the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink>
|
||||
and <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink>
|
||||
variables to your <filename>local.conf</filename> file,
|
||||
which is found in the
|
||||
variables to your <filename>local.conf</filename> file,
|
||||
which is found in the
|
||||
<link linkend='build-directory'>Build Directory</link>:
|
||||
<literallayout class='monospaced'>
|
||||
EXTRA_IMAGE_FEATURES += "ptest"
|
||||
EXTRA_IMAGE_FEATURES += "ptest"
|
||||
DISTRO_FEATURES_append = " ptest-pkgs"
|
||||
</literallayout>
|
||||
Once your build is complete, the ptest files are installed
|
||||
into the <filename>/usr/lib/<package>/ptest</filename>
|
||||
directory within the image, where
|
||||
<filename><package></filename> is the name of the
|
||||
directory within the image, where
|
||||
<filename><package></filename> is the name of the
|
||||
package.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -3592,21 +3592,21 @@
|
|||
<title>Running ptest</title>
|
||||
|
||||
<para>
|
||||
The <filename>ptest-runner</filename> package installs a
|
||||
shell script that loops through all installed ptest test
|
||||
suites and runs them in sequence.
|
||||
The <filename>ptest-runner</filename> package installs a
|
||||
shell script that loops through all installed ptest test
|
||||
suites and runs them in sequence.
|
||||
Consequently, you might want to add this package to
|
||||
your image.
|
||||
your image.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='getting-your-package-ready'>
|
||||
<title>Getting Your Package Ready</title>
|
||||
|
||||
|
||||
<para>
|
||||
In order to enable a recipe to run installed ptests
|
||||
on target hardware,
|
||||
you need to prepare the recipes that build the packages
|
||||
In order to enable a recipe to run installed ptests
|
||||
on target hardware,
|
||||
you need to prepare the recipes that build the packages
|
||||
you want to test.
|
||||
Here is what you have to do for each recipe:
|
||||
<itemizedlist>
|
||||
|
|
@ -3619,10 +3619,10 @@
|
|||
</para></listitem>
|
||||
<listitem><para><emphasis>Create <filename>run-ptest</filename>:</emphasis>
|
||||
This script starts your test.
|
||||
Locate the script where you will refer to it
|
||||
using
|
||||
Locate the script where you will refer to it
|
||||
using
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
|
||||
Here is an example that starts a test for
|
||||
Here is an example that starts a test for
|
||||
<filename>dbus</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
#!/bin/sh
|
||||
|
|
@ -3632,45 +3632,45 @@
|
|||
</para></listitem>
|
||||
<listitem><para><emphasis>Ensure dependencies are
|
||||
met:</emphasis>
|
||||
If the test adds build or runtime dependencies
|
||||
that normally do not exist for the package
|
||||
(such as requiring "make" to run the test suite),
|
||||
use the
|
||||
If the test adds build or runtime dependencies
|
||||
that normally do not exist for the package
|
||||
(such as requiring "make" to run the test suite),
|
||||
use the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
|
||||
and
|
||||
and
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>
|
||||
variables in your recipe in order for the package
|
||||
to meet the dependencies.
|
||||
Here is an example where the package has a runtime
|
||||
to meet the dependencies.
|
||||
Here is an example where the package has a runtime
|
||||
dependency on "make":
|
||||
<literallayout class='monospaced'>
|
||||
RDEPENDS_${PN}-ptest += "make"
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Add a function to build the
|
||||
<listitem><para><emphasis>Add a function to build the
|
||||
test suite:</emphasis>
|
||||
Not many packages support cross-compilation of
|
||||
their test suites.
|
||||
Consequently, you usually need to add a
|
||||
Not many packages support cross-compilation of
|
||||
their test suites.
|
||||
Consequently, you usually need to add a
|
||||
cross-compilation function to the package.
|
||||
</para>
|
||||
<para>Many packages based on Automake compile and
|
||||
<para>Many packages based on Automake compile and
|
||||
run the test suite by using a single command
|
||||
such as <filename>make check</filename>.
|
||||
However, the native <filename>make check</filename>
|
||||
builds and runs on the same computer, while
|
||||
cross-compiling requires that the package is built
|
||||
builds and runs on the same computer, while
|
||||
cross-compiling requires that the package is built
|
||||
on the host but executed on the target.
|
||||
The built version of Automake that ships with the
|
||||
Yocto Project includes a patch that separates
|
||||
The built version of Automake that ships with the
|
||||
Yocto Project includes a patch that separates
|
||||
building and execution.
|
||||
Consequently, packages that use the unaltered,
|
||||
Consequently, packages that use the unaltered,
|
||||
patched version of <filename>make check</filename>
|
||||
automatically cross-compiles.</para>
|
||||
<para>However, you still must add a
|
||||
<filename>do_compile_ptest</filename> function to
|
||||
<para>However, you still must add a
|
||||
<filename>do_compile_ptest</filename> function to
|
||||
build the test suite.
|
||||
Add a function similar to the following to your
|
||||
Add a function similar to the following to your
|
||||
recipe:
|
||||
<literallayout class='monospaced'>
|
||||
do_compile_ptest() {
|
||||
|
|
@ -3680,26 +3680,26 @@
|
|||
</para></listitem>
|
||||
<listitem><para><emphasis>Ensure special configurations
|
||||
are set:</emphasis>
|
||||
If the package requires special configurations
|
||||
If the package requires special configurations
|
||||
prior to compiling the test code, you must
|
||||
insert a <filename>do_configure_ptest</filename>
|
||||
function into the recipe.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Install the test
|
||||
<listitem><para><emphasis>Install the test
|
||||
suite:</emphasis>
|
||||
The <filename>ptest.bbclass</filename> class
|
||||
automatically copies the file
|
||||
<filename>run-ptest</filename> to the target and
|
||||
The <filename>ptest.bbclass</filename> class
|
||||
automatically copies the file
|
||||
<filename>run-ptest</filename> to the target and
|
||||
then runs make <filename>install-ptest</filename>
|
||||
to run the tests.
|
||||
If this is not enough, you need to create a
|
||||
<filename>do_install_ptest</filename> function and
|
||||
make sure it gets called after the
|
||||
to run the tests.
|
||||
If this is not enough, you need to create a
|
||||
<filename>do_install_ptest</filename> function and
|
||||
make sure it gets called after the
|
||||
"make install-ptest" completes.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
|
|
@ -3771,20 +3771,22 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
If you want to use <filename>SysVinit</filename>, you do
|
||||
If you want to use <filename>sysvinit</filename>, you do
|
||||
not have to do anything.
|
||||
But, if you want to use <filename>systemd</filename>, you must
|
||||
take some steps as described in the following sections.
|
||||
</para>
|
||||
|
||||
<!--
|
||||
<note>
|
||||
It is recommended that you create your own distribution configuration
|
||||
file to hold these settings instead of using your
|
||||
file to hold these settings instead of using your
|
||||
<filename>local.conf</filename> file.
|
||||
For information on creating your own distribution, see the
|
||||
For information on creating your own distribution, see the
|
||||
"<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
|
||||
section.
|
||||
</note>
|
||||
-->
|
||||
|
||||
<section id='using-systemd-exclusively'>
|
||||
<title>Using systemd Exclusively</title>
|
||||
|
|
@ -3797,7 +3799,7 @@
|
|||
VIRTUAL-RUNTIME_init_manager = "systemd"
|
||||
</literallayout>
|
||||
You can also prevent the <filename>sysvinit</filename>
|
||||
distribution feature from
|
||||
distribution feature from
|
||||
being automatically enabled as follows:
|
||||
<literallayout class='monospaced'>
|
||||
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
|
||||
|
|
@ -3805,6 +3807,12 @@
|
|||
Doing so removes any redundant <filename>sysvinit</filename>
|
||||
scripts.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For information on the backfill variable, see
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></ulink>
|
||||
in the Yocto Project Reference Manual.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='using-systemd-for-the-main-image-and-using-sysvinit-for-the-rescue-image'>
|
||||
|
|
@ -3838,7 +3846,7 @@
|
|||
However, on rare occasions where you might want to use a
|
||||
layer but exclude parts that are causing problems, such
|
||||
as introducing a different version of a recipe, you can
|
||||
use
|
||||
use
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBMASK'><filename>BBMASK</filename></ulink>
|
||||
to exclude the recipe.
|
||||
</para>
|
||||
|
|
@ -3978,7 +3986,7 @@
|
|||
creation:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Not using $D in front of absolute paths:</emphasis>
|
||||
The build system defines
|
||||
The build system defines
|
||||
<filename>$</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink>
|
||||
at root filesystem creation time, and
|
||||
it is blank when run on the target device.
|
||||
|
|
@ -4034,9 +4042,9 @@
|
|||
</para>
|
||||
|
||||
<tip>
|
||||
For best results, install <filename>-dbg</filename> packages for
|
||||
For best results, install <filename>-dbg</filename> packages for
|
||||
the applications you are going to debug.
|
||||
Doing so makes extra debug symbols available that give you more
|
||||
Doing so makes extra debug symbols available that give you more
|
||||
meaningful output.
|
||||
</tip>
|
||||
|
||||
|
|
@ -4097,11 +4105,11 @@
|
|||
<para>
|
||||
Before you can initiate a remote debugging session, you need
|
||||
to be sure you have set up the cross-development environment,
|
||||
toolchain, and sysroot.
|
||||
toolchain, and sysroot.
|
||||
The "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-prepare'>Preparing for Application Development</ulink>"
|
||||
chapter of the Yocto Project Application Developer's Guide
|
||||
describes this process.
|
||||
Be sure you have read that chapter and have set up
|
||||
Be sure you have read that chapter and have set up
|
||||
your environment.
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -4111,22 +4119,22 @@
|
|||
|
||||
<para>
|
||||
Make sure Gdbserver is installed on the target.
|
||||
If it is not, install the package
|
||||
If it is not, install the package
|
||||
<filename>gdbserver</filename>, which needs the
|
||||
<filename>libthread-db1</filename> package.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is an example that when entered from the host
|
||||
connects to the target and launches Gdbserver in order to
|
||||
Here is an example that when entered from the host
|
||||
connects to the target and launches Gdbserver in order to
|
||||
"debug" a binary named <filename>helloworld</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ gdbserver localhost:2345 /usr/bin/helloworld
|
||||
</literallayout>
|
||||
Gdbserver should now be listening on port 2345 for debugging
|
||||
commands coming from a remote GDB process that is running on
|
||||
commands coming from a remote GDB process that is running on
|
||||
the host computer.
|
||||
Communication between Gdbserver and the host GDB are done
|
||||
Communication between Gdbserver and the host GDB are done
|
||||
using TCP.
|
||||
To use other communication protocols, please refer to the
|
||||
<ulink url='http://www.gnu.org/software/gdb/'>Gdbserver documentation</ulink>.
|
||||
|
|
@ -4144,23 +4152,23 @@
|
|||
<section id="platdev-gdb-remotedebug-launch-gdb-buildcross">
|
||||
<title>Build the Cross-GDB Package</title>
|
||||
<para>
|
||||
A suitable GDB cross-binary is required that runs on your
|
||||
host computer but also knows about the the ABI of the
|
||||
A suitable GDB cross-binary is required that runs on your
|
||||
host computer but also knows about the the ABI of the
|
||||
remote target.
|
||||
You can get this binary from the
|
||||
You can get this binary from the
|
||||
<link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
|
||||
Here is an example where the toolchain has been installed
|
||||
in the default directory
|
||||
in the default directory
|
||||
<filename>/opt/poky/&DISTRO;</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
/opt/poky/1.4/sysroots/i686-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
|
||||
</literallayout>
|
||||
where <filename>arm</filename> is the target architecture
|
||||
where <filename>arm</filename> is the target architecture
|
||||
and <filename>linux-gnueabi</filename> is the target ABI.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Alternatively, you can use BitBake to build the
|
||||
Alternatively, you can use BitBake to build the
|
||||
<filename>gdb-cross</filename> binary.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -4190,10 +4198,10 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
You need to add a statement in the
|
||||
You need to add a statement in the
|
||||
<filename>.gdbinit</filename> file that points to your
|
||||
root filesystem.
|
||||
Here is an example that points to the root filesystem for
|
||||
Here is an example that points to the root filesystem for
|
||||
an ARM-based target device:
|
||||
<literallayout class='monospaced'>
|
||||
set sysroot /home/jzhang/sysroot_arm
|
||||
|
|
@ -4205,14 +4213,14 @@
|
|||
<title>Launch the Host GDB</title>
|
||||
|
||||
<para>
|
||||
Before launching the host GDB, you need to be sure
|
||||
you have sourced the cross-debugging environment script,
|
||||
which if you installed the root filesystem in the default
|
||||
location is at <filename>/opt/poky/&DISTRO;</filename>
|
||||
Before launching the host GDB, you need to be sure
|
||||
you have sourced the cross-debugging environment script,
|
||||
which if you installed the root filesystem in the default
|
||||
location is at <filename>/opt/poky/&DISTRO;</filename>
|
||||
and begins with the string "environment-setup".
|
||||
For more information, see the
|
||||
For more information, see the
|
||||
"<ulink url='&YOCTO_DOCS_ADT_URL;#setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</ulink>"
|
||||
section in the Yocto Project Application Developer's
|
||||
section in the Yocto Project Application Developer's
|
||||
Guide.
|
||||
</para>
|
||||
|
||||
|
|
@ -4222,7 +4230,7 @@
|
|||
Provide the binary file you are going to debug.
|
||||
For example, the following command continues with the
|
||||
example used in the previous section by loading
|
||||
the <filename>helloworld</filename> binary as well as the
|
||||
the <filename>helloworld</filename> binary as well as the
|
||||
debugging information:
|
||||
<literallayout class='monospaced'>
|
||||
$ arm-poky-linux-gnuabi-gdb helloworld
|
||||
|
|
@ -4238,7 +4246,7 @@
|
|||
|
||||
<para>
|
||||
From the target, you need to connect to the remote GDB
|
||||
server that is running on the host.
|
||||
server that is running on the host.
|
||||
You need to specify the remote host and port.
|
||||
Here is the command continuing with the example:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -4315,7 +4323,7 @@
|
|||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DEBUG_BUILD'>DEBUG_BUILD</ulink></filename>
|
||||
variable to "1" in the <filename>local.conf</filename> configuration file.
|
||||
If you use the <filename>DEBUG_BUILD</filename> variable,
|
||||
you also add extra debugging information that can make the debug
|
||||
you also add extra debugging information that can make the debug
|
||||
packages large.
|
||||
</para>
|
||||
|
||||
|
|
@ -4390,8 +4398,8 @@
|
|||
<ulink url="&YOCTO_GIT_URL;/cgit.cgi/oprofileui/"></ulink>.
|
||||
If the "tools-profile" image feature is selected, all necessary binaries
|
||||
are installed onto the target device for OProfileUI interaction.
|
||||
For a list of image features that ship with the Yocto Project,
|
||||
see the
|
||||
For a list of image features that ship with the Yocto Project,
|
||||
see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-features-image'>Images</ulink>"
|
||||
section in the Yocto Project Reference Manual.
|
||||
</para>
|
||||
|
|
@ -4460,7 +4468,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Downloaded archives reside in the
|
||||
Downloaded archives reside in the
|
||||
<link linkend='build-directory'>Build Directory</link> in
|
||||
<filename>/tmp</filename> and are cleared up when they are no longer in use.
|
||||
</para>
|
||||
|
|
@ -4604,7 +4612,7 @@
|
|||
release of proprietary software.
|
||||
The Yocto Project provides an archiver class to help avoid
|
||||
some of these concerns.
|
||||
See the
|
||||
See the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-archiver'>Archiving Sources - <filename>archive*.bbclass</filename></ulink>"
|
||||
section in the Yocto Project Reference Manual for information
|
||||
on this class.
|
||||
|
|
@ -4752,7 +4760,7 @@
|
|||
##COREBASE##/meta-yocto \
|
||||
"
|
||||
</literallayout>
|
||||
Creating and providing an archive of the
|
||||
Creating and providing an archive of the
|
||||
<link linkend='metadata'>Metadata</link> layers
|
||||
(recipes, configuration files, and so forth)
|
||||
enables you to meet your
|
||||
|
|
|
|||
Loading…
Reference in New Issue