sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

documentation/poky-ref-manual/extendpoky.xml: multilib edits 

Feedback from Richard Purdie inserted.  I made an edit pass for
style to Richard's re-write.

(From yocto-docs rev: e5bb08e966614c610e6357642b3b2d1522332f7f)

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 2011-10-03 07:42:20 -07:00 committed by Richard Purdie
parent f05471dcf8
commit 2a68be025b
1 changed files with 136 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

228
documentation/poky-ref-manual/extendpoky.xml
View File

@ -1073,14 +1073,36 @@
</section> </section>
<section id="building-multiple-architecture-libraries-into-one-image"> <section id="building-multiple-architecture-libraries-into-one-image">
<title>Building Multiple Architecture Libraries into One Image</title> <title>Combining Multiple versions of Library Files into One Image</title>
<para> <para>
By taking steps you can create a single image that contains more than The build system offers the ability to build libraries with different
one library for different architectures. target optimizations or architecture formats and combine these together
This feature is called "Multilib". into one system image.
This section overviews the process only. You can link different binaries in the image
For more detail on how to implement this feature, see the against the different libraries as needed for specific use cases.
This feature is called "Multilib."
</para>
<para>
An example would be where you have most of a system compiled in 32-bit
mode using 32-bit libraries, but you have something large, like a database
engine, that needs to be a 64-bit application and use 64-bit libraries.
Multilib allows you to get the best of both 32-bit and 64-bit libraries.
</para>
<para>
While the Multilib feature is most commonly used for 32 and 64-bit differences,
the approach the build system uses facilitates different target optimizations.
You could compile some binaries to use one set of libraries and other binaries
to use other different sets of libraries.
The libraries could differ in architecture, compiler options, or other
optimizations.
</para>
<para>
This section overviews the Multilib process only.
For more details on how to implement Multilib, see the
<ulink url='https://wiki.yoctoproject.org/wiki/Multilib'>Multilib</ulink> wiki <ulink url='https://wiki.yoctoproject.org/wiki/Multilib'>Multilib</ulink> wiki
page. page.
</para> </para>
@ -1089,105 +1111,127 @@
<title>Preparing to use Multilib</title> <title>Preparing to use Multilib</title>
<para> <para>
In order to implement Multilib, you need to prepare your recipes and packages as User-specific requirements drive the Multilib feature,
follows: Consequently, there is no one "out-of-the-box" configuration that likely
<itemizedlist> exists to meet your needs.
<listitem><para>Use the <filename>BBCLASSEXTEND</filename> variable to enable
a recipe for Multilib.
See the <filename>meta/conf/multilib.conf</filename> configuration file
in the Yocto Project Files directory to see how this variable is used.
</para></listitem>
<listitem><para>Define a global variable <filename>${MLPREFIX}</filename>
to specify the libraries (e.g. "<filename>lib32-'</filename>" or
"<filename>lib64-</filename>").</para></listitem>
<listitem><para>Rename your recipe to be <filename>${MLPREFIX}${PN}</filename>.
</para></listitem>
<listitem><para>For any recipe that uses Multilib and specifies lists of
recipes or packages with variables such as <filename>DEPENDS</filename>,
<filename>RDEPENDS</filename>,
<filename>RPROVIDES</filename>, <filename>RRECOMMENDS</filename>,
<filename>PACKAGES</filename>, <filename>PACKAGES_DYNAMIC</filename>,
map those recipes or packages with <filename>${MLPREFIX}</filename>.
</para></listitem>
</itemizedlist>
</para> </para>
<para> <para>
Next, be sure that the correct cross-toolchain parameters are used In order to enable Multilib, you first need to ensure your recipe is
by setting <filename>DEFAULTTUNE_virtclass-multilib-xxx</filename> extended to support multiple libraries.
in the <filename>local.conf</filename> configuration file in the Many standard recipes are already extended and support multiple libraries.
Yocto Project build directory. You can check in the <filename>meta/conf/multilib.conf</filename>
configuration file in the Yocto Project files directory to see how this is
done using the <filename>BBCLASSEXTEND</filename> variable.
Eventually, all recipes will be covered and this list will be unneeded.
</para> </para>
<para> <para>
If you are using the RPM Package Management System, you need to consider the For the most part, the Multilib class extension works automatically to
following: extend the package name from <filename>${PN}</filename> to
<itemizedlist> <filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
<listitem><para>Define the unique architecure for the Multilib packages, along with is the particular multilib (e.g. "lib32-" or "lib64-").
creating a unique deploy folder under <filename>tmp/deploy/rpm</filename> in Standard variables such as <filename>DEPENDS</filename>,
the Yocto Project build directory. <filename>RDEPENDS</filename>, <filename>RPROVIDES</filename>,
For example, consider <filename>lib32</filename> in a <filename>RRECOMMENDS</filename>, <filename>PACKAGES</filename>, and
<filename>qemux86-64</filename> image. <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
The possible architectures in the system are "all", "qemux86_64", "lib32_qemux86_64", If you are extending any manual code in the recipe, you can use the
and "lib32_x86".</para></listitem> <filename>${MLPREFIX}</filename> variable to ensure those names are extended
<listitem><para>Because the <filename>${MLPREFIX}</filename> is stripped from correctly.
<filename>${PN}</filename> during RPM packaging, the naming for a normal This automatic extension code resides in <filename>multilib.bbclass</filename>.
RPM package and a Multilib RPM package in a <filename>qemux86-64</filename>
system resolves to something similar to <filename>bash-4.1-r2.x86_64.rpm</filename> and
<filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.</para></listitem>
<listitem><para>When installing a Multilib image, the RPM backend first installs
the base image and then installs the Multilib libraries.</para></listitem>
</itemizedlist>
</para> </para>
</section>
<para>
If you are using the IPK Package Management System, you need to consider the
following:
<itemizedlist>
<listitem><para><filename>${MLPREFIX}</filename> is not stripped from
<filename>${PN}</filename> during IPK packaging, the naming for a normal
RPM package and a Multilib IPK package in a <filename>qemux86-64</filename>
system resolves to something like <filename>bash_4.1-r2.x86_64.ipk</filename> and
<filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.</para></listitem>
<listitem><para>The IPK deploy folder is not modified with
<filename>${MLPREFIX}</filename> because packages with and without
the Multilib feature can exist in the same folder due to the
<filename>${PN}</filename> differences.</para></listitem>
<listitem><para>IPK defines a sanity check for Multilib installation using certain
rules for file comparison, overridden, etc.</para></listitem>
</itemizedlist>
</para>
</section>
<section id='using-multilib'> <section id='using-multilib'>
<title>Using Multilib</title> <title>Using Multilib</title>
<para> <para>
After you have set up the recipies and configurations to use the Multilib feature, After you have set up the recipes, you need to define the actual
you are ready to build the image. combination of multiple libraries you want to build.
Follow these steps: You accomplish this through your <filename>local.conf</filename>
<orderedlist> configuration file in the Yocto Project build directory.
<listitem><para>Make changes in your <filename>local.conf</filename> An example configuration would be as follows:
configuration file in the Yocto Project build directory. <literallayout class='monospaced'>
Here is an example: MACHINE = "qemux86-64"
<literallayout class='monospaced'> require conf/multilib.conf
MULTILIB_IMAGE(INSTALL = "lib32-connman"
require conf/multilib.con
MULTILIBS = "multilib:lib32" MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86" DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
</literallayout></para></listitem> MULTILIB_IMAGE_INSTALL = "lib32-connman"
<listitem><para>Build the image using the BitBake command. </literallayout>
For example: This example enables an
<literallayout class='monospaced'> additional library named <filename>lib32</filename> alongside the
normal target packages.
When combining these "lib32" alternatives, the example uses "x86" for tuning.
For information on this particular tuning, see
<filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
</para>
<para>
The example then includes <filename>lib32-connman</filename>
in all the images, which illustrates one method of including a
multiple library dependency.
You can use a normal image build to include this dependency,
for example:
<literallayout class='monospaced'>
$ bitbake core-image-sato $ bitbake core-image-sato
</literallayout> </literallayout>
If you want to build a particular recipe only, You can also build Multilib packages specifically with a command like this:
use the BitBake command and specify the recipe only. <literallayout class='monospaced'>
For example: $ bitbake lib32-connman
<literallayout class='monospaced'> </literallayout>
$ bitbake lib32-connman </para>
</literallayout></para></listitem> </section>
</orderedlist>
<section id='additional-implementation-details'>
<title>Additional Implementation Details</title>
<para>
Different packaging systems have different levels of native Multilib
support.
For the RPM Package Management System, the following implementation details
exist:
<itemizedlist>
<listitem><para>A unique architecture is defined for the Multilib packages,
along with creating a unique deploy folder under
<filename>tmp/deploy/rpm</filename> in the Yocto
Project build directory.
For example, consider <filename>lib32</filename> in a
<filename>qemux86-64</filename> image.
The possible architectures in the system are "all", "qemux86_64",
"lib32_qemux86_64", and "lib32_x86".</para></listitem>
<listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from
<filename>${PN}</filename> during RPM packaging.
The naming for a normal RPM package and a Multilib RPM package in a
<filename>qemux86-64</filename> system resolves to something similar to
<filename>bash-4.1-r2.x86_64.rpm</filename> and
<filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
</para></listitem>
<listitem><para>When installing a Multilib image, the RPM backend first
installs the base image and then installs the Multilib libraries.
</para></listitem>
<listitem><para>The build system relies on RPM to resolve the identical files in the
two (or more) Multilib packages.</para></listitem>
</itemizedlist>
</para>
<para>
For the IPK Package Management System, the following implementation details exist:
<itemizedlist>
<listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from
<filename>${PN}</filename> during IPK packaging.
The naming for a normal RPM package and a Multilib IPK package in a
<filename>qemux86-64</filename> system resolves to something like
<filename>bash_4.1-r2.x86_64.ipk</filename> and
<filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.
</para></listitem>
<listitem><para>The IPK deploy folder is not modified with
<filename>${MLPREFIX}</filename> because packages with and without
the Multilib feature can exist in the same folder due to the
<filename>${PN}</filename> differences.</para></listitem>
<listitem><para>IPK defines a sanity check for Multilib installation
using certain rules for file comparison, overridden, etc.
</para></listitem>
</itemizedlist>
</para> </para>
</section> </section>
</section> </section>