Multilib - Revision history

PaulEggleton: All still relevant content now merged into the YP dev manual, so turn this into a link to the appropriate section

2016-04-27T01:27:31Z

All still relevant content now merged into the YP dev manual, so turn this into a link to the appropriate section

← Older revision		Revision as of 01:27, 27 April 2016
Line 1:		Line 1:
	~~=== Vision ===~~		Please see [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-library-files-into-one-image Combining Multiple Versions of Library Files into One Image] in the Yocto Project Development manual.
	~~Provide the ability to build multiple arch library in one image, for example, in x86_64 arch, provide lib32, lib64, or even libx32.~~

	~~=== Basic Infrastructure ===~~

	~~Recipe~~/~~Package name handling.~~
	* Use BBCLASSEXTEND to make a certain recipe multilib capable. See meta/~~conf/multilib~~.~~conf~~
	* Define a global variable ${MLPREFIX} that is likely "lib32-" or "lib64-".
	* Rename the recipe name to be ${MLPREFIX}${PN}.
	* For a certain recipe, map all its DEPENDS, RDEPENDS, RPROVIDES, RRECOMMENDS, PACKAGES, PACKAGES_DYNAMIC, etc with ${MLPREFIX}.

	~~Multilib target architecture and build options selection.~~
	* By setting DEFAULTTUNE_virtclass-multilib-xxx in local.conf to select target multilib architecture (see following examples). ~~Certain parameters will be selected for toolchain accordingly. (See different tune files under "meta~~/~~conf~~/~~machine~~/~~include/")~~

	~~RPM backend.~~
	* Define unique architecture for multilib packages, along with creating unique deploy folder under tmp/deploy/rpm. (Take lib32 on qemux86-64 as an example, the possible architectures in the system are: "all", "qemux86_64", "x86_64", "lib32_qemux86_64", and "lib32_x86" ).
	* The ${MLPREFIX} will be stripped from ${PN} when doing RPM packaging. Therefore the naming for normal RPM package and multilib RPM package in a qemux86-64 system are something like "bash-4.1-r2.x86_64.rpm" and " bash-4.1-~~r2.lib32_x86.rpm".~~
	* When installing a multilib image, the RPM backend will firstly install the base image, then install the multilib libraries.

	~~IPK backend.~~
	* ${MLPREFIX} will NOT be stripped from ${PN} when doing IPK packaging. Therefore the normal and multilib IPK packages are something like: "bash_4.1-r2_x86_64.ipk" and "lib32-bash_4.1-r2_x86.ipk".
	* IPK deploy folder will not be added with ${MLPREFIX} since normal and multilib packages can exist in the same folder due to the ${PN} differences.
	* IPK defines a kind of sanity check for multilib installation with certain rules on file comparison, overridden, etc.

	~~=== How to use it ===~~

	~~Build an image with multilib libraries (qemux86-64 machine with lib32-connman):~~

	* Setting the following in local.conf.
	~~IMAGE_INSTALL_append = " lib32-connman"~~
	~~require conf~~/~~multilib.conf~~
	~~MULTILIBS = "multilib:lib32"~~
	~~DEFAULTTUNE_virtclass-multilib-lib32 = "x86"~~
	* bitbake core-image-sato

	~~If user wants to build certain multilib recipe (lib32-connman):~~

	* bitbake lib32-connman

	~~=== Current Status ===~~

	* Multilib feature works fine within core-image-minimal and core-image-~~sato images~~.

	* core-~~image~~-~~sato~~-~~sdk and core~~-~~image~~-~~lsb will be worked on after 1.1 release.~~

	~~===Notes===~~
	~~This is one of Richard's initial email before the multilib task begin:~~

	"
	~~There have been a few issues and some lessons to learn. I've also have to make some implementation decisions based on the issues we were running~~ into~~. To summarize them:~~

	* bitbake has issues if you try and delete variables from the data store. Patches two and three on the branch fix the issues I was seeing. More details are in the commits.

	* I found the recent additional event in bitbake wasn't in the right place to optimally support multilib so I had to move the expandKeys() call. Since the only known user is the native/nativesdk classes in OE-~~Core, this should be ok to do at this point. Again, the commit has the specific details.~~

	* When adding parameter support to BBCLASSEXTEND I added some variables so the class can figure out which class is being processed and what the parameter is. Related to this is the issue that bbclass event handlers once added always get called, even if the class isn't inherited in a subsequent recipe file!

	* I switched to using <multilib>- as the prefix for multilib recipes. This was because using the ":" character didn't work out as it gets placed into paths in too many places if you add it to PN.

	* I've made the assumption that if a name in PACKAGES uses PN, its at the start.

	* The use of := in cross.bbclass makes life hard for multilib. There is a special section of multilib.bbclass devoted to handling those variables. Initially I approached this as two separate multilib classes but these are merged together now.

	* I set the TARGET_VENDOR to the horrendously ugly string "-pokymllib32". The reason is that any "-" characters in there breaks config.sub at present and other separators cause other issues. I suspect we can fix that going forward but for now it works albeit looking horrible.

	* I had to introduce MLPREFIX for use in certain places, thankfully all in places "normal" recipes shouldn't need to use it.

	~~=== Task Breakdown ===~~

	~~# Change libdir to "lib64" for qemux86~~-~~64 and see what breaks.~~
	~~# Extend MULTILIB class extension to recipes required to build:~~
	~~## minimal image~~
	~~## LSB image?~~
	~~## Sato~~ image?
	~~## world [stretch goal for 1.1]~~
	~~#: This task also could include a better way~~ of ~~specifying which recipes to extend.~~
	~~# Add support to RPM packaging backend to turn modified package names~~ into ~~true rpm multilib packages.~~
	~~# Add support to standard opkg backend to allow parallel install of multilib variant packages (likely to be hacky at first but also include a proposal for better native opkg support of this)~~
	~~# Add support to bitbake to pass BBEXTEND parameters from options like bitbake -b where filenames are specified on the commandline~~
	~~# Create some "standard" multilib configurations (x86 32+64 bit)~~
	~~# Overhaul architecture, ABI, optimisation configuration files with a view to better structure (and ease specifying multilib configurations).~~
	~~# Reconsolidate multilib + multilibcross class differences [already done by RP now~~]
	~~# Directly support multlibs within~~ the ~~toolchain itself [post 1.1]~~
	~~# Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-" but it might be possible to relax that constraint~~.

PaulEggleton at 08:19, 7 April 2015

2015-04-07T08:19:52Z

← Older revision		Revision as of 08:19, 7 April 2015
Line 28:		Line 28:

	* Setting the following in local.conf.		* Setting the following in local.conf.
	~~IMAGE_INSTALL~~ = "lib32-connman"		IMAGE_INSTALL_append = " lib32-connman"
	require conf/multilib.conf		require conf/multilib.conf
	MULTILIBS = "multilib:lib32"		MULTILIBS = "multilib:lib32"

Kai.kang: /* How to use it */ - Changed MULTILIB_IMAGE_INSTALL to IMAGE_INSTALL (yocto-docs rev: dfcbecf94)

2013-08-06T08:47:25Z

How to use it: - Changed MULTILIB_IMAGE_INSTALL to IMAGE_INSTALL (yocto-docs rev: dfcbecf94)

← Older revision		Revision as of 08:47, 6 August 2013
Line 28:		Line 28:

	* Setting the following in local.conf.		* Setting the following in local.conf.
	~~MULTILIB_IMAGE_INSTALL~~ = "lib32-connman"		IMAGE_INSTALL = "lib32-connman"
	require conf/multilib.conf		require conf/multilib.conf
	MULTILIBS = "multilib:lib32"		MULTILIBS = "multilib:lib32"

Dongxiao.xu: /* Task Breakdown */

2011-09-29T08:45:41Z

Task Breakdown

← Older revision		Revision as of 08:45, 29 September 2011
Line 66:		Line 66:
	* I had to introduce MLPREFIX for use in certain places, thankfully all in places "normal" recipes shouldn't need to use it.		* I had to introduce MLPREFIX for use in certain places, thankfully all in places "normal" recipes shouldn't need to use it.

	== Task Breakdown ==		=== Task Breakdown ===

	# Change libdir to "lib64" for qemux86-64 and see what breaks.		# Change libdir to "lib64" for qemux86-64 and see what breaks.

Dongxiao.xu: /* Vision */

2011-09-29T08:45:16Z

Vision

← Older revision		Revision as of 08:45, 29 September 2011
Line 1:		Line 1:
	== Vision ==		=== Vision ===
	Provide the ability to build multiple arch library in one image, for example, in x86_64 arch, provide lib32, lib64, or even libx32.		Provide the ability to build multiple arch library in one image, for example, in x86_64 arch, provide lib32, lib64, or even libx32.

Dongxiao.xu: /* Basic Infrastructure */

2011-09-29T08:44:42Z

Basic Infrastructure

@@ Line 2: / Line 2: @@
 Provide the ability to build multiple arch library in one image, for example, in x86_64 arch, provide lib32, lib64, or even libx32.
-== Basic Infrastructure ==
+=== Basic Infrastructure ===
-Richard already work out the basic infrastructure in '''http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml'''
 ===Notes===
+"
@@ Line 25: / Line 65: @@
 * I had to introduce MLPREFIX for use in certain places, thankfully all in places "normal" recipes shouldn't need to use it.
 == Task Breakdown ==

Yuke: /* Basic Infrastructure */

2011-06-23T07:16:45Z

Basic Infrastructure

← Older revision		Revision as of 07:16, 23 June 2011
Line 3:		Line 3:

	== Basic Infrastructure ==		== Basic Infrastructure ==
	Richard already work out the ~~base~~ infrastructure '''http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml'''		Richard already work out the basic infrastructure in '''http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml'''

	===Notes===		===Notes===

Yuke at 07:15, 23 June 2011

2011-06-23T07:15:26Z

← Older revision		Revision as of 07:15, 23 June 2011
Line 42:		Line 42:
	## Sato image?		## Sato image?
	## world [stretch goal for 1.1]		## world [stretch goal for 1.1]
	This task also could include a better way of specifying which recipes to extend.		#: This task also could include a better way of specifying which recipes to extend.
	# Add support to RPM packaging backend to turn modified package names into true rpm multilib packages.		# Add support to RPM packaging backend to turn modified package names into true rpm multilib packages.
	# Add support to standard opkg backend to allow parallel install of multilib variant packages (likely to be hacky at first but also include a proposal for better native opkg support of this)		# Add support to standard opkg backend to allow parallel install of multilib variant packages (likely to be hacky at first but also include a proposal for better native opkg support of this)

Yuke at 07:12, 23 June 2011

2011-06-23T07:12:09Z

← Older revision		Revision as of 07:12, 23 June 2011
Line 36:		Line 36:
	== Task Breakdown ==		== Task Breakdown ==

	*#) Change libdir to "lib64" for qemux86-64 and see what breaks.		# Change libdir to "lib64" for qemux86-64 and see what breaks.
			# Extend MULTILIB class extension to recipes required to build:
	2) Extend MULTILIB class extension to recipes required to build:		## minimal image
	a) minimal image		## LSB image?
	b) LSB image?		## Sato image?
	c) Sato image?		## world [stretch goal for 1.1]
	d) world [stretch goal for 1.1]		This task also could include a better way of specifying which recipes to extend.
			# Add support to RPM packaging backend to turn modified package names into true rpm multilib packages.
	This task also could include a better way of specifying which		# Add support to standard opkg backend to allow parallel install of multilib variant packages (likely to be hacky at first but also include a proposal for better native opkg support of this)
	recipes to extend.		# Add support to bitbake to pass BBEXTEND parameters from options like bitbake -b where filenames are specified on the commandline
			# Create some "standard" multilib configurations (x86 32+64 bit)
	3) Add support to RPM packaging backend to turn modified package names		# Overhaul architecture, ABI, optimisation configuration files with a view to better structure (and ease specifying multilib configurations).
	into true rpm multilib packages.		# Reconsolidate multilib + multilibcross class differences [already done by RP now]
			# Directly support multlibs within the toolchain itself [post 1.1]
	4) Add support to standard opkg backend to allow parallel install of		# Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-" but it might be possible to relax that constraint.
	multilib variant packages (likely to be hacky at first but also
	include a proposal for better native opkg support of this)

	5) Add support to bitbake to pass BBEXTEND parameters from options like
	bitbake -b where filenames are specified on the commandline

	6) Create some "standard" multilib configurations (x86 32+64 bit)

	7) Overhaul architecture, ABI, optimisation configuration files with a
	view to better structure (and ease specifying multilib
	configurations).

	8) Reconsolidate multilib + multilibcross class differences [already
	done by RP now]

	9) Directly support multlibs within the toolchain itself [post 1.1]

	~~10)~~ Investigate better TARGET_VENDOR handling for config.sub. Currently
	we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-"
	but it might be possible to relax that constraint.

Yuke at 07:05, 23 June 2011

2011-06-23T07:05:33Z

@@ Line 5: / Line 5: @@
 Richard already work out the base infrastructure '''http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml'''
-'''Notes'''
+===Notes===
+"
@@ Line 26: / Line 26: @@
 * I had to introduce MLPREFIX for use in certain places, thankfully all in places "normal" recipes shouldn't need to use it.
-''' How to use it '''
+=== How to use it ===
-* Step 1: add the following in local.conf
+* Step 1: add the following in local.conf:
-require conf/multilib.conf
+  require conf/multilib.conf
-MULTILIBS = "multilib:lib32 multilib:lib64"
+* Step 2:
-* Step 2: bitbake zlib lib64-zlib lib32-zlib
+== Task Breakdown ==
-== Task Breakdown ==
+) Directly support multlibs within the toolchain itself [post 1.1]