diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index 18d7b258aa..e08332d948 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -981,61 +981,6 @@ -
- Including Static Library Files - - - If you are building a library and the library offers static linking, you can control - which static library files (*.a files) get included in the - built library. - - - - The PACKAGES - and FILES_* - variables in the - meta/conf/bitbake.conf configuration file define how files installed - by the do_install task are packaged. - By default, the PACKAGES variable contains - ${PN}-staticdev, which includes all static library files. - - Previously released versions of the Yocto Project defined the static library files - through ${PN}-dev. - - Following, is part of the BitBake configuration file. - You can see where the static library files are defined: - - 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})" - - -
-
Post Install Scripts @@ -1235,188 +1180,281 @@
-
- Combining Multiple Versions of Library Files into One Image +
+ Working With Libraries - 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 - - 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. - - - - 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. - - - - This section overviews the Multilib process only. - For more details on how to implement Multilib, see the - Multilib wiki - page. - - - - Aside from this wiki page, several examples exist in the - meta-skeleton - layer found in the - Source Directory: - - multilib-example.conf - configuration file - multilib-example2.conf - configuration file - recipes-multilib/images/core-image-multilib-example.bb - recipe - - - -
- Preparing to use Multilib +
+ Including Static Library Files - 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 (*.a files) get included in the + built library. - 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 meta/conf/multilib.conf - configuration file in the - Source Directory to see how this is - done using the - BBCLASSEXTEND - variable. - Eventually, all recipes will be covered and this list will be unneeded. - + The PACKAGES + and FILES_* + variables in the + meta/conf/bitbake.conf configuration file define how files installed + by the do_install task are packaged. + By default, the PACKAGES variable contains + ${PN}-staticdev, which includes all static library files. + + Previously released versions of the Yocto Project defined the static library files + through ${PN}-dev. + + Following, is part of the BitBake configuration file. + You can see where the static library files are defined: + + PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale" + PACKAGES_DYNAMIC = "${PN}-locale-*" + FILES = "" - - For the most part, the Multilib class extension works automatically to - extend the package name from ${PN} to - ${MLPREFIX}${PN}, where MLPREFIX - is the particular multilib (e.g. "lib32-" or "lib64-"). - Standard variables such as - DEPENDS, - RDEPENDS, - RPROVIDES, - RRECOMMENDS, - PACKAGES, - and PACKAGES_DYNAMIC are automatically extended by the system. - If you are extending any manual code in the recipe, you can use the - ${MLPREFIX} variable to ensure those names are extended - correctly. - This automatic extension code resides in multilib.bbclass. + 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})" +
-
- Using Multilib +
+ Combining Multiple Versions of Library Files into One Image - 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 local.conf - configuration file in the - Build Directory. - An example configuration would be as follows: - + 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." + + + + 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. + + + + 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. + + + + This section overviews the Multilib process only. + For more details on how to implement Multilib, see the + Multilib wiki + page. + + + + Aside from this wiki page, several examples exist in the + meta-skeleton + layer found in the + Source Directory: + + multilib-example.conf + configuration file + multilib-example2.conf + configuration file + recipes-multilib/images/core-image-multilib-example.bb + recipe + + + +
+ Preparing to use Multilib + + + User-specific requirements drive the Multilib feature, + Consequently, there is no one "out-of-the-box" configuration that likely + exists to meet your needs. + + + + 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 meta/conf/multilib.conf + configuration file in the + Source Directory to see how this is + done using the + BBCLASSEXTEND + variable. + Eventually, all recipes will be covered and this list will be unneeded. + + + + For the most part, the Multilib class extension works automatically to + extend the package name from ${PN} to + ${MLPREFIX}${PN}, where MLPREFIX + is the particular multilib (e.g. "lib32-" or "lib64-"). + Standard variables such as + DEPENDS, + RDEPENDS, + RPROVIDES, + RRECOMMENDS, + PACKAGES, + and PACKAGES_DYNAMIC are automatically extended by the system. + If you are extending any manual code in the recipe, you can use the + ${MLPREFIX} variable to ensure those names are extended + correctly. + This automatic extension code resides in multilib.bbclass. + +
+ +
+ Using Multilib + + + 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 local.conf + configuration file in the + Build Directory. + An example configuration would be as follows: + MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL = "lib32-connman" - - This example enables an - additional library named lib32 alongside the - normal target packages. - When combining these "lib32" alternatives, the example uses "x86" for tuning. - For information on this particular tuning, see - meta/conf/machine/include/ia32/arch-ia32.inc. - + + This example enables an + additional library named lib32 alongside the + normal target packages. + When combining these "lib32" alternatives, the example uses "x86" for tuning. + For information on this particular tuning, see + meta/conf/machine/include/ia32/arch-ia32.inc. + - - The example then includes lib32-connman - 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: - + + The example then includes lib32-connman + 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: + $ bitbake core-image-sato - - You can also build Multilib packages specifically with a command like this: - + + You can also build Multilib packages specifically with a command like this: + $ bitbake lib32-connman - - + + +
+ +
+ Additional Implementation Details + + + Different packaging systems have different levels of native Multilib + support. + For the RPM Package Management System, the following implementation details + exist: + + A unique architecture is defined for the Multilib packages, + along with creating a unique deploy folder under + tmp/deploy/rpm in the + Build Directory. + For example, consider lib32 in a + qemux86-64 image. + The possible architectures in the system are "all", "qemux86_64", + "lib32_qemux86_64", and "lib32_x86". + The ${MLPREFIX} variable is stripped from + ${PN} during RPM packaging. + The naming for a normal RPM package and a Multilib RPM package in a + qemux86-64 system resolves to something similar to + bash-4.1-r2.x86_64.rpm and + bash-4.1.r2.lib32_x86.rpm, respectively. + + When installing a Multilib image, the RPM backend first + installs the base image and then installs the Multilib libraries. + + The build system relies on RPM to resolve the identical files in the + two (or more) Multilib packages. + + + + + For the IPK Package Management System, the following implementation details exist: + + The ${MLPREFIX} is not stripped from + ${PN} during IPK packaging. + The naming for a normal RPM package and a Multilib IPK package in a + qemux86-64 system resolves to something like + bash_4.1-r2.x86_64.ipk and + lib32-bash_4.1-rw_x86.ipk, respectively. + + The IPK deploy folder is not modified with + ${MLPREFIX} because packages with and without + the Multilib feature can exist in the same folder due to the + ${PN} differences. + IPK defines a sanity check for Multilib installation + using certain rules for file comparison, overridden, etc. + + + +
-
- Additional Implementation Details +
+ Installing Multiple Versions of the Same Library - Different packaging systems have different levels of native Multilib - support. - For the RPM Package Management System, the following implementation details - exist: - - A unique architecture is defined for the Multilib packages, - along with creating a unique deploy folder under - tmp/deploy/rpm in the - Build Directory. - For example, consider lib32 in a - qemux86-64 image. - The possible architectures in the system are "all", "qemux86_64", - "lib32_qemux86_64", and "lib32_x86". - The ${MLPREFIX} variable is stripped from - ${PN} during RPM packaging. - The naming for a normal RPM package and a Multilib RPM package in a - qemux86-64 system resolves to something similar to - bash-4.1-r2.x86_64.rpm and - bash-4.1.r2.lib32_x86.rpm, respectively. - - When installing a Multilib image, the RPM backend first - installs the base image and then installs the Multilib libraries. - - The build system relies on RPM to resolve the identical files in the - two (or more) Multilib packages. - - - - - For the IPK Package Management System, the following implementation details exist: - - The ${MLPREFIX} is not stripped from - ${PN} during IPK packaging. - The naming for a normal RPM package and a Multilib IPK package in a - qemux86-64 system resolves to something like - bash_4.1-r2.x86_64.ipk and - lib32-bash_4.1-rw_x86.ipk, respectively. - - The IPK deploy folder is not modified with - ${MLPREFIX} because packages with and without - the Multilib feature can exist in the same folder due to the - ${PN} differences. - IPK defines a sanity check for Multilib installation - using certain rules for file comparison, overridden, etc. - - + + (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 +