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:
Scott Rifenbark
Richard Purdie
parent
ef0ef862c1
commit
d0edd46ebb
|
|
@ -981,61 +981,6 @@
|
|||
</para>
|
||||
</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'>
|
||||
<title>Post Install Scripts</title>
|
||||
|
||||
|
|
@ -1235,188 +1180,281 @@
|
|||
</section>
|
||||
</section>
|
||||
|
||||
<section id="building-multiple-architecture-libraries-into-one-image">
|
||||
<title>Combining Multiple Versions of Library Files into One Image</title>
|
||||
<section id="platdev-working-with-libraries">
|
||||
<title>Working With Libraries</title>
|
||||
|
||||
<para>
|
||||
The build system offers the ability to build libraries with different
|
||||
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."
|
||||
Intro text
|
||||
</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>
|
||||
<section id='including-static-library-files'>
|
||||
<title>Including Static Library Files</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.
|
||||
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>
|
||||
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>
|
||||
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 = ""
|
||||
|
||||
<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>.
|
||||
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='using-multilib'>
|
||||
<title>Using Multilib</title>
|
||||
<section id="combining-multiple-versions-library-files-into-one-image">
|
||||
<title>Combining Multiple Versions of Library Files into One Image</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'>
|
||||
The build system offers the ability to build libraries with different
|
||||
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>
|
||||
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"
|
||||
require conf/multilib.conf
|
||||
MULTILIBS = "multilib:lib32"
|
||||
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
|
||||
IMAGE_INSTALL = "lib32-connman"
|
||||
</literallayout>
|
||||
This example enables an
|
||||
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>
|
||||
</literallayout>
|
||||
This example enables an
|
||||
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'>
|
||||
<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
|
||||
</literallayout>
|
||||
You can also build Multilib packages specifically with a command like this:
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
You can also build Multilib packages specifically with a command like this:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake lib32-connman
|
||||
</literallayout>
|
||||
</para>
|
||||
</literallayout>
|
||||
</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 id='additional-implementation-details'>
|
||||
<title>Additional Implementation Details</title>
|
||||
<section id='installing-multiple-versions-of-the-same-library'>
|
||||
<title>Installing Multiple Versions of the Same Library</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>
|
||||
<literallayout class='monospaced'>
|
||||
(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?
|
||||
(08:06:44 AM) paul.eggleton: scottrif: it's still a valid use case I think
|
||||
(08:06:59 AM) scottrif: paul.eggleton: ok - thanks
|
||||
(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
|
||||
(08:08:07 AM) paul.eggleton: so e.g. for clutter, PN is clutter-1.8 rather than just clutter
|
||||
(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?
|
||||
(08:09:52 AM) paul.eggleton: scottrif: no, you need to provide a separate recipe for each version
|
||||
(08:09:59 AM) paul.eggleton: scottrif: so the PN would come from the file name
|
||||
(08:10:07 AM) paul.eggleton: (as normal)
|
||||
(08:10:24 AM) paul.eggleton: so e.g. the recipe might be clutter-1.8_1.8.4.bb
|
||||
(08:10:30 AM) scottrif: paul.eggleton: ok - one version per library version and each recipe specifically uses PN to indicate the version.
|
||||
(08:10:48 AM) paul.eggleton: the major part of the version, yes
|
||||
(08:10:48 AM) scottrif: paul.eggleton: I mean one "recipe" per library version :)
|
||||
(08:11:18 AM) scottrif: paul.eggleton: major being "1.8" in your example
|
||||
(08:11:33 AM) paul.eggleton: right, in this instance one recipe per major version since the API got changed between the two
|
||||
(08:11:56 AM) paul.eggleton: (which is the typical cause of needing to do this multiple version exercise)
|
||||
(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?
|
||||
(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
|
||||
(08:14:22 AM) paul.eggleton: in fact I can't think of another reason why you'd want to do this
|
||||
(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 :)
|
||||
(08:14:52 AM) paul.eggleton: scottrif: sure thing
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
|||
Loading…
Reference in New Issue