dev-manual: Reorganization for section using libraries
Fixes YOCTO #1548 Created a new section called "Working With Libraries". This section is a parent section for all the stuff about libraries. Previously, there were two other sections dealing with libraries: one was mulitlib section and one was about loading static libraries. It makes sense to have a parent section now that gathers the three sub-sections together. I have reorganized the chapter structure to accomplish this. Also, I placed some IRC chat notes temporarily into the new section that will discuss how to load multiple versions of the same library in parallel on the system. (From yocto-docs rev: 5d150421bcd660a191aff63ebabd577cc19bd421) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
ef0ef862c1
commit
d0edd46ebb
|
@ -981,61 +981,6 @@
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='including-static-library-files'>
|
|
||||||
<title>Including Static Library Files</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
If you are building a library and the library offers static linking, you can control
|
|
||||||
which static library files (<filename>*.a</filename> files) get included in the
|
|
||||||
built library.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
The <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
|
|
||||||
and <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES_*</filename></ulink>
|
|
||||||
variables in the
|
|
||||||
<filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
|
|
||||||
by the <filename>do_install</filename> task are packaged.
|
|
||||||
By default, the <filename>PACKAGES</filename> variable contains
|
|
||||||
<filename>${PN}-staticdev</filename>, which includes all static library files.
|
|
||||||
<note>
|
|
||||||
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.
|
|
||||||
You can see where the static library files are defined:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
|
|
||||||
PACKAGES_DYNAMIC = "${PN}-locale-*"
|
|
||||||
FILES = ""
|
|
||||||
|
|
||||||
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
|
|
||||||
${sysconfdir} ${sharedstatedir} ${localstatedir} \
|
|
||||||
${base_bindir}/* ${base_sbindir}/* \
|
|
||||||
${base_libdir}/*${SOLIBS} \
|
|
||||||
${datadir}/${BPN} ${libdir}/${BPN}/* \
|
|
||||||
${datadir}/pixmaps ${datadir}/applications \
|
|
||||||
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
|
|
||||||
${libdir}/bonobo/servers"
|
|
||||||
|
|
||||||
FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
|
|
||||||
${datadir}/gnome/help"
|
|
||||||
SECTION_${PN}-doc = "doc"
|
|
||||||
|
|
||||||
FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
|
|
||||||
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
|
|
||||||
${datadir}/aclocal ${base_libdir}/*.o"
|
|
||||||
SECTION_${PN}-dev = "devel"
|
|
||||||
ALLOW_EMPTY_${PN}-dev = "1"
|
|
||||||
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
|
|
||||||
|
|
||||||
FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
|
|
||||||
SECTION_${PN}-staticdev = "devel"
|
|
||||||
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
|
|
||||||
</literallayout>
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id='usingpoky-extend-addpkg-postinstalls'>
|
<section id='usingpoky-extend-addpkg-postinstalls'>
|
||||||
<title>Post Install Scripts</title>
|
<title>Post Install Scripts</title>
|
||||||
|
|
||||||
|
@ -1235,188 +1180,281 @@
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id="building-multiple-architecture-libraries-into-one-image">
|
<section id="platdev-working-with-libraries">
|
||||||
<title>Combining Multiple Versions of Library Files into One Image</title>
|
<title>Working With Libraries</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The build system offers the ability to build libraries with different
|
Intro text
|
||||||
target optimizations or architecture formats and combine these together
|
|
||||||
into one system image.
|
|
||||||
You can link different binaries in the image
|
|
||||||
against the different libraries as needed for specific use cases.
|
|
||||||
This feature is called "Multilib."
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<section id='including-static-library-files'>
|
||||||
An example would be where you have most of a system compiled in 32-bit
|
<title>Including Static Library Files</title>
|
||||||
mode using 32-bit libraries, but you have something large, like a database
|
|
||||||
engine, that needs to be a 64-bit application and uses 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='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki
|
|
||||||
page.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Aside from this wiki page, several examples exist in the
|
|
||||||
<ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/tree/meta-skeleton'><filename>meta-skeleton</filename></ulink>
|
|
||||||
layer found in the
|
|
||||||
<link linkend='source-directory'>Source Directory</link>:
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem><para><filename>multilib-example.conf</filename>
|
|
||||||
configuration file</para></listitem>
|
|
||||||
<listitem><para><filename>multilib-example2.conf</filename>
|
|
||||||
configuration file</para></listitem>
|
|
||||||
<listitem><para><filename>recipes-multilib/images/core-image-multilib-example.bb</filename>
|
|
||||||
recipe</para></listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<section id='preparing-to-use-multilib'>
|
|
||||||
<title>Preparing to use Multilib</title>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
User-specific requirements drive the Multilib feature,
|
If you are building a library and the library offers static linking, you can control
|
||||||
Consequently, there is no one "out-of-the-box" configuration that likely
|
which static library files (<filename>*.a</filename> files) get included in the
|
||||||
exists to meet your needs.
|
built library.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In order to enable Multilib, you first need to ensure your recipe is
|
The <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
|
||||||
extended to support multiple libraries.
|
and <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES_*</filename></ulink>
|
||||||
Many standard recipes are already extended and support multiple libraries.
|
variables in the
|
||||||
You can check in the <filename>meta/conf/multilib.conf</filename>
|
<filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
|
||||||
configuration file in the
|
by the <filename>do_install</filename> task are packaged.
|
||||||
<link linkend='source-directory'>Source Directory</link> to see how this is
|
By default, the <filename>PACKAGES</filename> variable contains
|
||||||
done using the
|
<filename>${PN}-staticdev</filename>, which includes all static library files.
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
|
<note>
|
||||||
variable.
|
Previously released versions of the Yocto Project defined the static library files
|
||||||
Eventually, all recipes will be covered and this list will be unneeded.
|
through <filename>${PN}-dev</filename>.
|
||||||
</para>
|
</note>
|
||||||
|
Following, is part of the BitBake configuration file.
|
||||||
|
You can see where the static library files are defined:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
|
PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
|
||||||
|
PACKAGES_DYNAMIC = "${PN}-locale-*"
|
||||||
|
FILES = ""
|
||||||
|
|
||||||
<para>
|
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
|
||||||
For the most part, the Multilib class extension works automatically to
|
${sysconfdir} ${sharedstatedir} ${localstatedir} \
|
||||||
extend the package name from <filename>${PN}</filename> to
|
${base_bindir}/* ${base_sbindir}/* \
|
||||||
<filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
|
${base_libdir}/*${SOLIBS} \
|
||||||
is the particular multilib (e.g. "lib32-" or "lib64-").
|
${datadir}/${BPN} ${libdir}/${BPN}/* \
|
||||||
Standard variables such as
|
${datadir}/pixmaps ${datadir}/applications \
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>,
|
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>,
|
${libdir}/bonobo/servers"
|
||||||
<filename>RPROVIDES</filename>,
|
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>,
|
FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>,
|
${datadir}/gnome/help"
|
||||||
and <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
|
SECTION_${PN}-doc = "doc"
|
||||||
If you are extending any manual code in the recipe, you can use the
|
|
||||||
<filename>${MLPREFIX}</filename> variable to ensure those names are extended
|
FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
|
||||||
correctly.
|
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
|
||||||
This automatic extension code resides in <filename>multilib.bbclass</filename>.
|
${datadir}/aclocal ${base_libdir}/*.o"
|
||||||
|
SECTION_${PN}-dev = "devel"
|
||||||
|
ALLOW_EMPTY_${PN}-dev = "1"
|
||||||
|
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
|
||||||
|
|
||||||
|
FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
|
||||||
|
SECTION_${PN}-staticdev = "devel"
|
||||||
|
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
|
||||||
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='using-multilib'>
|
<section id="combining-multiple-versions-library-files-into-one-image">
|
||||||
<title>Using Multilib</title>
|
<title>Combining Multiple Versions of Library Files into One Image</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
After you have set up the recipes, you need to define the actual
|
The build system offers the ability to build libraries with different
|
||||||
combination of multiple libraries you want to build.
|
target optimizations or architecture formats and combine these together
|
||||||
You accomplish this through your <filename>local.conf</filename>
|
into one system image.
|
||||||
configuration file in the
|
You can link different binaries in the image
|
||||||
<link linkend='build-directory'>Build Directory</link>.
|
against the different libraries as needed for specific use cases.
|
||||||
An example configuration would be as follows:
|
This feature is called "Multilib."
|
||||||
<literallayout class='monospaced'>
|
</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 uses 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='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki
|
||||||
|
page.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Aside from this wiki page, several examples exist in the
|
||||||
|
<ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/tree/meta-skeleton'><filename>meta-skeleton</filename></ulink>
|
||||||
|
layer found in the
|
||||||
|
<link linkend='source-directory'>Source Directory</link>:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem><para><filename>multilib-example.conf</filename>
|
||||||
|
configuration file</para></listitem>
|
||||||
|
<listitem><para><filename>multilib-example2.conf</filename>
|
||||||
|
configuration file</para></listitem>
|
||||||
|
<listitem><para><filename>recipes-multilib/images/core-image-multilib-example.bb</filename>
|
||||||
|
recipe</para></listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<section id='preparing-to-use-multilib'>
|
||||||
|
<title>Preparing to use Multilib</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
User-specific requirements drive the Multilib feature,
|
||||||
|
Consequently, there is no one "out-of-the-box" configuration that likely
|
||||||
|
exists to meet your needs.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
In order to enable Multilib, you first need to ensure your recipe is
|
||||||
|
extended to support multiple libraries.
|
||||||
|
Many standard recipes are already extended and support multiple libraries.
|
||||||
|
You can check in the <filename>meta/conf/multilib.conf</filename>
|
||||||
|
configuration file in the
|
||||||
|
<link linkend='source-directory'>Source Directory</link> to see how this is
|
||||||
|
done using the
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
|
||||||
|
variable.
|
||||||
|
Eventually, all recipes will be covered and this list will be unneeded.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
For the most part, the Multilib class extension works automatically to
|
||||||
|
extend the package name from <filename>${PN}</filename> to
|
||||||
|
<filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
|
||||||
|
is the particular multilib (e.g. "lib32-" or "lib64-").
|
||||||
|
Standard variables such as
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>,
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>,
|
||||||
|
<filename>RPROVIDES</filename>,
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>,
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>,
|
||||||
|
and <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
|
||||||
|
If you are extending any manual code in the recipe, you can use the
|
||||||
|
<filename>${MLPREFIX}</filename> variable to ensure those names are extended
|
||||||
|
correctly.
|
||||||
|
This automatic extension code resides in <filename>multilib.bbclass</filename>.
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section id='using-multilib'>
|
||||||
|
<title>Using Multilib</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
After you have set up the recipes, you need to define the actual
|
||||||
|
combination of multiple libraries you want to build.
|
||||||
|
You accomplish this through your <filename>local.conf</filename>
|
||||||
|
configuration file in the
|
||||||
|
<link linkend='build-directory'>Build Directory</link>.
|
||||||
|
An example configuration would be as follows:
|
||||||
|
<literallayout class='monospaced'>
|
||||||
MACHINE = "qemux86-64"
|
MACHINE = "qemux86-64"
|
||||||
require conf/multilib.conf
|
require conf/multilib.conf
|
||||||
MULTILIBS = "multilib:lib32"
|
MULTILIBS = "multilib:lib32"
|
||||||
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
|
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
|
||||||
IMAGE_INSTALL = "lib32-connman"
|
IMAGE_INSTALL = "lib32-connman"
|
||||||
</literallayout>
|
</literallayout>
|
||||||
This example enables an
|
This example enables an
|
||||||
additional library named <filename>lib32</filename> alongside the
|
additional library named <filename>lib32</filename> alongside the
|
||||||
normal target packages.
|
normal target packages.
|
||||||
When combining these "lib32" alternatives, the example uses "x86" for tuning.
|
When combining these "lib32" alternatives, the example uses "x86" for tuning.
|
||||||
For information on this particular tuning, see
|
For information on this particular tuning, see
|
||||||
<filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
|
<filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The example then includes <filename>lib32-connman</filename>
|
The example then includes <filename>lib32-connman</filename>
|
||||||
in all the images, which illustrates one method of including a
|
in all the images, which illustrates one method of including a
|
||||||
multiple library dependency.
|
multiple library dependency.
|
||||||
You can use a normal image build to include this dependency,
|
You can use a normal image build to include this dependency,
|
||||||
for example:
|
for example:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
$ bitbake core-image-sato
|
$ bitbake core-image-sato
|
||||||
</literallayout>
|
</literallayout>
|
||||||
You can also build Multilib packages specifically with a command like this:
|
You can also build Multilib packages specifically with a command like this:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
$ bitbake lib32-connman
|
$ bitbake lib32-connman
|
||||||
</literallayout>
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<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
|
||||||
|
<link linkend='build-directory'>Build Directory</link>.
|
||||||
|
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>
|
||||||
|
</section>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='additional-implementation-details'>
|
<section id='installing-multiple-versions-of-the-same-library'>
|
||||||
<title>Additional Implementation Details</title>
|
<title>Installing Multiple Versions of the Same Library</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Different packaging systems have different levels of native Multilib
|
<literallayout class='monospaced'>
|
||||||
support.
|
(08:04:38 AM) scottrif: RP: I am looking at an old bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=1548) regarding documenting how multiple different library versions of a library can be built and installed in parallel on a system. You mention Clutter as a good example of this. Before I start diving into this can you tell me if it is still relevant given the bug was filed in Oct. of 2011?
|
||||||
For the RPM Package Management System, the following implementation details
|
(08:06:44 AM) paul.eggleton: scottrif: it's still a valid use case I think
|
||||||
exist:
|
(08:06:59 AM) scottrif: paul.eggleton: ok - thanks
|
||||||
<itemizedlist>
|
(08:07:43 AM) paul.eggleton: it's not too tricky assuming the library uses proper versioning itself; if it does you just need to ensure something version-specific appears in PN
|
||||||
<listitem><para>A unique architecture is defined for the Multilib packages,
|
(08:08:07 AM) paul.eggleton: so e.g. for clutter, PN is clutter-1.8 rather than just clutter
|
||||||
along with creating a unique deploy folder under
|
(08:09:25 AM) scottrif: paul.eggleton: so PN specifies version 1.8 in your example. Do you put multiple PN statements somewhere to accomplish installing multiple versions of the same library?
|
||||||
<filename>tmp/deploy/rpm</filename> in the
|
(08:09:52 AM) paul.eggleton: scottrif: no, you need to provide a separate recipe for each version
|
||||||
<link linkend='build-directory'>Build Directory</link>.
|
(08:09:59 AM) paul.eggleton: scottrif: so the PN would come from the file name
|
||||||
For example, consider <filename>lib32</filename> in a
|
(08:10:07 AM) paul.eggleton: (as normal)
|
||||||
<filename>qemux86-64</filename> image.
|
(08:10:24 AM) paul.eggleton: so e.g. the recipe might be clutter-1.8_1.8.4.bb
|
||||||
The possible architectures in the system are "all", "qemux86_64",
|
(08:10:30 AM) scottrif: paul.eggleton: ok - one version per library version and each recipe specifically uses PN to indicate the version.
|
||||||
"lib32_qemux86_64", and "lib32_x86".</para></listitem>
|
(08:10:48 AM) paul.eggleton: the major part of the version, yes
|
||||||
<listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from
|
(08:10:48 AM) scottrif: paul.eggleton: I mean one "recipe" per library version :)
|
||||||
<filename>${PN}</filename> during RPM packaging.
|
(08:11:18 AM) scottrif: paul.eggleton: major being "1.8" in your example
|
||||||
The naming for a normal RPM package and a Multilib RPM package in a
|
(08:11:33 AM) paul.eggleton: right, in this instance one recipe per major version since the API got changed between the two
|
||||||
<filename>qemux86-64</filename> system resolves to something similar to
|
(08:11:56 AM) paul.eggleton: (which is the typical cause of needing to do this multiple version exercise)
|
||||||
<filename>bash-4.1-r2.x86_64.rpm</filename> and
|
(08:12:15 AM) scottrif: paul.eggleton: okay - so what circumstances do I tell the reader when it is a good idea to do this besides the case you just stated?
|
||||||
<filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
|
(08:14:07 AM) paul.eggleton: it's almost always about an API change and you have other pieces of software that depend on both versions that you need to build and use at runtime within the same system
|
||||||
</para></listitem>
|
(08:14:22 AM) paul.eggleton: in fact I can't think of another reason why you'd want to do this
|
||||||
<listitem><para>When installing a Multilib image, the RPM backend first
|
(08:14:44 AM) scottrif: paul.eggleton: ok - I will stick to that one. Thanks! I will probably enlist you to check over the new section :)
|
||||||
installs the base image and then installs the Multilib libraries.
|
(08:14:52 AM) paul.eggleton: scottrif: sure thing
|
||||||
</para></listitem>
|
</literallayout>
|
||||||
<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>
|
||||||
|
|
Loading…
Reference in New Issue