summaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2013-03-22 08:58:06 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2013-04-04 14:12:48 +0100
commitd0edd46ebbcd681254ef70c97cd90b3f70cdc688 (patch)
tree9e81de965eea47494616e25209d6a7a971f21068 /documentation/dev-manual
parentef0ef862c10c0c8187601a2dab45ffe8c6f133e4 (diff)
downloadpoky-d0edd46ebbcd681254ef70c97cd90b3f70cdc688.tar.gz
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>
Diffstat (limited to 'documentation/dev-manual')
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.xml454
1 files changed, 246 insertions, 208 deletions
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 @@
981 </para> 981 </para>
982 </section> 982 </section>
983 983
984 <section id='including-static-library-files'>
985 <title>Including Static Library Files</title>
986
987 <para>
988 If you are building a library and the library offers static linking, you can control
989 which static library files (<filename>*.a</filename> files) get included in the
990 built library.
991 </para>
992
993 <para>
994 The <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
995 and <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES_*</filename></ulink>
996 variables in the
997 <filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
998 by the <filename>do_install</filename> task are packaged.
999 By default, the <filename>PACKAGES</filename> variable contains
1000 <filename>${PN}-staticdev</filename>, which includes all static library files.
1001 <note>
1002 Previously released versions of the Yocto Project defined the static library files
1003 through <filename>${PN}-dev</filename>.
1004 </note>
1005 Following, is part of the BitBake configuration file.
1006 You can see where the static library files are defined:
1007 <literallayout class='monospaced'>
1008 PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
1009 PACKAGES_DYNAMIC = "${PN}-locale-*"
1010 FILES = ""
1011
1012 FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
1013 ${sysconfdir} ${sharedstatedir} ${localstatedir} \
1014 ${base_bindir}/* ${base_sbindir}/* \
1015 ${base_libdir}/*${SOLIBS} \
1016 ${datadir}/${BPN} ${libdir}/${BPN}/* \
1017 ${datadir}/pixmaps ${datadir}/applications \
1018 ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
1019 ${libdir}/bonobo/servers"
1020
1021 FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
1022 ${datadir}/gnome/help"
1023 SECTION_${PN}-doc = "doc"
1024
1025 FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
1026 ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
1027 ${datadir}/aclocal ${base_libdir}/*.o"
1028 SECTION_${PN}-dev = "devel"
1029 ALLOW_EMPTY_${PN}-dev = "1"
1030 RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
1031
1032 FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
1033 SECTION_${PN}-staticdev = "devel"
1034 RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
1035 </literallayout>
1036 </para>
1037 </section>
1038
1039 <section id='usingpoky-extend-addpkg-postinstalls'> 984 <section id='usingpoky-extend-addpkg-postinstalls'>
1040 <title>Post Install Scripts</title> 985 <title>Post Install Scripts</title>
1041 986
@@ -1235,188 +1180,281 @@
1235 </section> 1180 </section>
1236 </section> 1181 </section>
1237 1182
1238 <section id="building-multiple-architecture-libraries-into-one-image"> 1183 <section id="platdev-working-with-libraries">
1239 <title>Combining Multiple Versions of Library Files into One Image</title> 1184 <title>Working With Libraries</title>
1240 1185
1241 <para> 1186 <para>
1242 The build system offers the ability to build libraries with different 1187 Intro text
1243 target optimizations or architecture formats and combine these together
1244 into one system image.
1245 You can link different binaries in the image
1246 against the different libraries as needed for specific use cases.
1247 This feature is called "Multilib."
1248 </para> 1188 </para>
1249 1189
1250 <para> 1190 <section id='including-static-library-files'>
1251 An example would be where you have most of a system compiled in 32-bit 1191 <title>Including Static Library Files</title>
1252 mode using 32-bit libraries, but you have something large, like a database
1253 engine, that needs to be a 64-bit application and uses 64-bit libraries.
1254 Multilib allows you to get the best of both 32-bit and 64-bit libraries.
1255 </para>
1256 1192
1257 <para> 1193 <para>
1258 While the Multilib feature is most commonly used for 32 and 64-bit differences, 1194 If you are building a library and the library offers static linking, you can control
1259 the approach the build system uses facilitates different target optimizations. 1195 which static library files (<filename>*.a</filename> files) get included in the
1260 You could compile some binaries to use one set of libraries and other binaries 1196 built library.
1261 to use other different sets of libraries. 1197 </para>
1262 The libraries could differ in architecture, compiler options, or other
1263 optimizations.
1264 </para>
1265 1198
1266 <para> 1199 <para>
1267 This section overviews the Multilib process only. 1200 The <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
1268 For more details on how to implement Multilib, see the 1201 and <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES_*</filename></ulink>
1269 <ulink url='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki 1202 variables in the
1270 page. 1203 <filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
1271 </para> 1204 by the <filename>do_install</filename> task are packaged.
1205 By default, the <filename>PACKAGES</filename> variable contains
1206 <filename>${PN}-staticdev</filename>, which includes all static library files.
1207 <note>
1208 Previously released versions of the Yocto Project defined the static library files
1209 through <filename>${PN}-dev</filename>.
1210 </note>
1211 Following, is part of the BitBake configuration file.
1212 You can see where the static library files are defined:
1213 <literallayout class='monospaced'>
1214 PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
1215 PACKAGES_DYNAMIC = "${PN}-locale-*"
1216 FILES = ""
1272 1217
1273 <para> 1218 FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
1274 Aside from this wiki page, several examples exist in the 1219 ${sysconfdir} ${sharedstatedir} ${localstatedir} \
1275 <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/tree/meta-skeleton'><filename>meta-skeleton</filename></ulink> 1220 ${base_bindir}/* ${base_sbindir}/* \
1276 layer found in the 1221 ${base_libdir}/*${SOLIBS} \
1277 <link linkend='source-directory'>Source Directory</link>: 1222 ${datadir}/${BPN} ${libdir}/${BPN}/* \
1278 <itemizedlist> 1223 ${datadir}/pixmaps ${datadir}/applications \
1279 <listitem><para><filename>multilib-example.conf</filename> 1224 ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
1280 configuration file</para></listitem> 1225 ${libdir}/bonobo/servers"
1281 <listitem><para><filename>multilib-example2.conf</filename> 1226
1282 configuration file</para></listitem> 1227 FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
1283 <listitem><para><filename>recipes-multilib/images/core-image-multilib-example.bb</filename> 1228 ${datadir}/gnome/help"
1284 recipe</para></listitem> 1229 SECTION_${PN}-doc = "doc"
1285 </itemizedlist> 1230
1286 </para> 1231 FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
1232 ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
1233 ${datadir}/aclocal ${base_libdir}/*.o"
1234 SECTION_${PN}-dev = "devel"
1235 ALLOW_EMPTY_${PN}-dev = "1"
1236 RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
1237
1238 FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
1239 SECTION_${PN}-staticdev = "devel"
1240 RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
1241 </literallayout>
1242 </para>
1243 </section>
1287 1244
1288 <section id='preparing-to-use-multilib'> 1245 <section id="combining-multiple-versions-library-files-into-one-image">
1289 <title>Preparing to use Multilib</title> 1246 <title>Combining Multiple Versions of Library Files into One Image</title>
1290 1247
1291 <para> 1248 <para>
1292 User-specific requirements drive the Multilib feature, 1249 The build system offers the ability to build libraries with different
1293 Consequently, there is no one "out-of-the-box" configuration that likely 1250 target optimizations or architecture formats and combine these together
1294 exists to meet your needs. 1251 into one system image.
1252 You can link different binaries in the image
1253 against the different libraries as needed for specific use cases.
1254 This feature is called "Multilib."
1295 </para> 1255 </para>
1296 1256
1297 <para> 1257 <para>
1298 In order to enable Multilib, you first need to ensure your recipe is 1258 An example would be where you have most of a system compiled in 32-bit
1299 extended to support multiple libraries. 1259 mode using 32-bit libraries, but you have something large, like a database
1300 Many standard recipes are already extended and support multiple libraries. 1260 engine, that needs to be a 64-bit application and uses 64-bit libraries.
1301 You can check in the <filename>meta/conf/multilib.conf</filename> 1261 Multilib allows you to get the best of both 32-bit and 64-bit libraries.
1302 configuration file in the
1303 <link linkend='source-directory'>Source Directory</link> to see how this is
1304 done using the
1305 <ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
1306 variable.
1307 Eventually, all recipes will be covered and this list will be unneeded.
1308 </para>
1309
1310 <para>
1311 For the most part, the Multilib class extension works automatically to
1312 extend the package name from <filename>${PN}</filename> to
1313 <filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
1314 is the particular multilib (e.g. "lib32-" or "lib64-").
1315 Standard variables such as
1316 <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>,
1317 <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>,
1318 <filename>RPROVIDES</filename>,
1319 <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>,
1320 <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>,
1321 and <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
1322 If you are extending any manual code in the recipe, you can use the
1323 <filename>${MLPREFIX}</filename> variable to ensure those names are extended
1324 correctly.
1325 This automatic extension code resides in <filename>multilib.bbclass</filename>.
1326 </para> 1262 </para>
1327 </section>
1328 1263
1329 <section id='using-multilib'> 1264 <para>
1330 <title>Using Multilib</title> 1265 While the Multilib feature is most commonly used for 32 and 64-bit differences,
1266 the approach the build system uses facilitates different target optimizations.
1267 You could compile some binaries to use one set of libraries and other binaries
1268 to use other different sets of libraries.
1269 The libraries could differ in architecture, compiler options, or other
1270 optimizations.
1271 </para>
1331 1272
1332 <para> 1273 <para>
1333 After you have set up the recipes, you need to define the actual 1274 This section overviews the Multilib process only.
1334 combination of multiple libraries you want to build. 1275 For more details on how to implement Multilib, see the
1335 You accomplish this through your <filename>local.conf</filename> 1276 <ulink url='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki
1336 configuration file in the 1277 page.
1337 <link linkend='build-directory'>Build Directory</link>. 1278 </para>
1338 An example configuration would be as follows: 1279
1339 <literallayout class='monospaced'> 1280 <para>
1281 Aside from this wiki page, several examples exist in the
1282 <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/tree/meta-skeleton'><filename>meta-skeleton</filename></ulink>
1283 layer found in the
1284 <link linkend='source-directory'>Source Directory</link>:
1285 <itemizedlist>
1286 <listitem><para><filename>multilib-example.conf</filename>
1287 configuration file</para></listitem>
1288 <listitem><para><filename>multilib-example2.conf</filename>
1289 configuration file</para></listitem>
1290 <listitem><para><filename>recipes-multilib/images/core-image-multilib-example.bb</filename>
1291 recipe</para></listitem>
1292 </itemizedlist>
1293 </para>
1294
1295 <section id='preparing-to-use-multilib'>
1296 <title>Preparing to use Multilib</title>
1297
1298 <para>
1299 User-specific requirements drive the Multilib feature,
1300 Consequently, there is no one "out-of-the-box" configuration that likely
1301 exists to meet your needs.
1302 </para>
1303
1304 <para>
1305 In order to enable Multilib, you first need to ensure your recipe is
1306 extended to support multiple libraries.
1307 Many standard recipes are already extended and support multiple libraries.
1308 You can check in the <filename>meta/conf/multilib.conf</filename>
1309 configuration file in the
1310 <link linkend='source-directory'>Source Directory</link> to see how this is
1311 done using the
1312 <ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
1313 variable.
1314 Eventually, all recipes will be covered and this list will be unneeded.
1315 </para>
1316
1317 <para>
1318 For the most part, the Multilib class extension works automatically to
1319 extend the package name from <filename>${PN}</filename> to
1320 <filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
1321 is the particular multilib (e.g. "lib32-" or "lib64-").
1322 Standard variables such as
1323 <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>,
1324 <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>,
1325 <filename>RPROVIDES</filename>,
1326 <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>,
1327 <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>,
1328 and <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
1329 If you are extending any manual code in the recipe, you can use the
1330 <filename>${MLPREFIX}</filename> variable to ensure those names are extended
1331 correctly.
1332 This automatic extension code resides in <filename>multilib.bbclass</filename>.
1333 </para>
1334 </section>
1335
1336 <section id='using-multilib'>
1337 <title>Using Multilib</title>
1338
1339 <para>
1340 After you have set up the recipes, you need to define the actual
1341 combination of multiple libraries you want to build.
1342 You accomplish this through your <filename>local.conf</filename>
1343 configuration file in the
1344 <link linkend='build-directory'>Build Directory</link>.
1345 An example configuration would be as follows:
1346 <literallayout class='monospaced'>
1340 MACHINE = "qemux86-64" 1347 MACHINE = "qemux86-64"
1341 require conf/multilib.conf 1348 require conf/multilib.conf
1342 MULTILIBS = "multilib:lib32" 1349 MULTILIBS = "multilib:lib32"
1343 DEFAULTTUNE_virtclass-multilib-lib32 = "x86" 1350 DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
1344 IMAGE_INSTALL = "lib32-connman" 1351 IMAGE_INSTALL = "lib32-connman"
1345 </literallayout> 1352 </literallayout>
1346 This example enables an 1353 This example enables an
1347 additional library named <filename>lib32</filename> alongside the 1354 additional library named <filename>lib32</filename> alongside the
1348 normal target packages. 1355 normal target packages.
1349 When combining these "lib32" alternatives, the example uses "x86" for tuning. 1356 When combining these "lib32" alternatives, the example uses "x86" for tuning.
1350 For information on this particular tuning, see 1357 For information on this particular tuning, see
1351 <filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>. 1358 <filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
1352 </para> 1359 </para>
1353 1360
1354 <para> 1361 <para>
1355 The example then includes <filename>lib32-connman</filename> 1362 The example then includes <filename>lib32-connman</filename>
1356 in all the images, which illustrates one method of including a 1363 in all the images, which illustrates one method of including a
1357 multiple library dependency. 1364 multiple library dependency.
1358 You can use a normal image build to include this dependency, 1365 You can use a normal image build to include this dependency,
1359 for example: 1366 for example:
1360 <literallayout class='monospaced'> 1367 <literallayout class='monospaced'>
1361 $ bitbake core-image-sato 1368 $ bitbake core-image-sato
1362 </literallayout> 1369 </literallayout>
1363 You can also build Multilib packages specifically with a command like this: 1370 You can also build Multilib packages specifically with a command like this:
1364 <literallayout class='monospaced'> 1371 <literallayout class='monospaced'>
1365 $ bitbake lib32-connman 1372 $ bitbake lib32-connman
1366 </literallayout> 1373 </literallayout>
1367 </para> 1374 </para>
1368 </section> 1375 </section>
1369 1376
1370 <section id='additional-implementation-details'> 1377 <section id='additional-implementation-details'>
1371 <title>Additional Implementation Details</title> 1378 <title>Additional Implementation Details</title>
1372 1379
1373 <para> 1380 <para>
1374 Different packaging systems have different levels of native Multilib 1381 Different packaging systems have different levels of native Multilib
1375 support. 1382 support.
1376 For the RPM Package Management System, the following implementation details 1383 For the RPM Package Management System, the following implementation details
1377 exist: 1384 exist:
1378 <itemizedlist> 1385 <itemizedlist>
1379 <listitem><para>A unique architecture is defined for the Multilib packages, 1386 <listitem><para>A unique architecture is defined for the Multilib packages,
1380 along with creating a unique deploy folder under 1387 along with creating a unique deploy folder under
1381 <filename>tmp/deploy/rpm</filename> in the 1388 <filename>tmp/deploy/rpm</filename> in the
1382 <link linkend='build-directory'>Build Directory</link>. 1389 <link linkend='build-directory'>Build Directory</link>.
1383 For example, consider <filename>lib32</filename> in a 1390 For example, consider <filename>lib32</filename> in a
1384 <filename>qemux86-64</filename> image. 1391 <filename>qemux86-64</filename> image.
1385 The possible architectures in the system are "all", "qemux86_64", 1392 The possible architectures in the system are "all", "qemux86_64",
1386 "lib32_qemux86_64", and "lib32_x86".</para></listitem> 1393 "lib32_qemux86_64", and "lib32_x86".</para></listitem>
1387 <listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from 1394 <listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from
1388 <filename>${PN}</filename> during RPM packaging. 1395 <filename>${PN}</filename> during RPM packaging.
1389 The naming for a normal RPM package and a Multilib RPM package in a 1396 The naming for a normal RPM package and a Multilib RPM package in a
1390 <filename>qemux86-64</filename> system resolves to something similar to 1397 <filename>qemux86-64</filename> system resolves to something similar to
1391 <filename>bash-4.1-r2.x86_64.rpm</filename> and 1398 <filename>bash-4.1-r2.x86_64.rpm</filename> and
1392 <filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively. 1399 <filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
1393 </para></listitem> 1400 </para></listitem>
1394 <listitem><para>When installing a Multilib image, the RPM backend first 1401 <listitem><para>When installing a Multilib image, the RPM backend first
1395 installs the base image and then installs the Multilib libraries. 1402 installs the base image and then installs the Multilib libraries.
1396 </para></listitem> 1403 </para></listitem>
1397 <listitem><para>The build system relies on RPM to resolve the identical files in the 1404 <listitem><para>The build system relies on RPM to resolve the identical files in the
1398 two (or more) Multilib packages.</para></listitem> 1405 two (or more) Multilib packages.</para></listitem>
1399 </itemizedlist> 1406 </itemizedlist>
1400 </para> 1407 </para>
1408
1409 <para>
1410 For the IPK Package Management System, the following implementation details exist:
1411 <itemizedlist>
1412 <listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from
1413 <filename>${PN}</filename> during IPK packaging.
1414 The naming for a normal RPM package and a Multilib IPK package in a
1415 <filename>qemux86-64</filename> system resolves to something like
1416 <filename>bash_4.1-r2.x86_64.ipk</filename> and
1417 <filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.
1418 </para></listitem>
1419 <listitem><para>The IPK deploy folder is not modified with
1420 <filename>${MLPREFIX}</filename> because packages with and without
1421 the Multilib feature can exist in the same folder due to the
1422 <filename>${PN}</filename> differences.</para></listitem>
1423 <listitem><para>IPK defines a sanity check for Multilib installation
1424 using certain rules for file comparison, overridden, etc.
1425 </para></listitem>
1426 </itemizedlist>
1427 </para>
1428 </section>
1429 </section>
1430
1431 <section id='installing-multiple-versions-of-the-same-library'>
1432 <title>Installing Multiple Versions of the Same Library</title>
1401 1433
1402 <para> 1434 <para>
1403 For the IPK Package Management System, the following implementation details exist: 1435 <literallayout class='monospaced'>
1404 <itemizedlist> 1436 (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?
1405 <listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from 1437(08:06:44 AM) paul.eggleton: scottrif: it's still a valid use case I think
1406 <filename>${PN}</filename> during IPK packaging. 1438(08:06:59 AM) scottrif: paul.eggleton: ok - thanks
1407 The naming for a normal RPM package and a Multilib IPK package in a 1439(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
1408 <filename>qemux86-64</filename> system resolves to something like 1440(08:08:07 AM) paul.eggleton: so e.g. for clutter, PN is clutter-1.8 rather than just clutter
1409 <filename>bash_4.1-r2.x86_64.ipk</filename> and 1441(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?
1410 <filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively. 1442(08:09:52 AM) paul.eggleton: scottrif: no, you need to provide a separate recipe for each version
1411 </para></listitem> 1443(08:09:59 AM) paul.eggleton: scottrif: so the PN would come from the file name
1412 <listitem><para>The IPK deploy folder is not modified with 1444(08:10:07 AM) paul.eggleton: (as normal)
1413 <filename>${MLPREFIX}</filename> because packages with and without 1445(08:10:24 AM) paul.eggleton: so e.g. the recipe might be clutter-1.8_1.8.4.bb
1414 the Multilib feature can exist in the same folder due to the 1446(08:10:30 AM) scottrif: paul.eggleton: ok - one version per library version and each recipe specifically uses PN to indicate the version.
1415 <filename>${PN}</filename> differences.</para></listitem> 1447(08:10:48 AM) paul.eggleton: the major part of the version, yes
1416 <listitem><para>IPK defines a sanity check for Multilib installation 1448(08:10:48 AM) scottrif: paul.eggleton: I mean one "recipe" per library version :)
1417 using certain rules for file comparison, overridden, etc. 1449(08:11:18 AM) scottrif: paul.eggleton: major being "1.8" in your example
1418 </para></listitem> 1450(08:11:33 AM) paul.eggleton: right, in this instance one recipe per major version since the API got changed between the two
1419 </itemizedlist> 1451(08:11:56 AM) paul.eggleton: (which is the typical cause of needing to do this multiple version exercise)
1452(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?
1453(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
1454(08:14:22 AM) paul.eggleton: in fact I can't think of another reason why you'd want to do this
1455(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 :)
1456(08:14:52 AM) paul.eggleton: scottrif: sure thing
1457 </literallayout>
1420 </para> 1458 </para>
1421 </section> 1459 </section>
1422 </section> 1460 </section>