Hi Mark, > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Mark Hatle > Sent: Tuesday, September 13, 2011 1:23 AM > To: [email protected] > Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs under > deploy/rpm > > On 9/12/11 10:07 AM, Xu, Dongxiao wrote: > > Hi Mark, > > > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf > >> Of Mark Hatle > >> Sent: Monday, September 12, 2011 10:56 PM > >> To: [email protected] > >> Subject: Re: [OE-core] [PATCH 2/3] rpm: add multilib prefix for archs > >> under deploy/rpm > >> > >> On 9/12/11 3:34 AM, Dongxiao Xu wrote: > >>> Currently MACHINE_ARCH deploy folder is unique in multilib system, > >>> thus a lib32 version of rpm package will override a normal rpm > >>> package if its PACKAGE_ARCH is ${MACHINE_ARCH}. > >>> > >>> Define different deploy folder for multilib architectures to avoid > >>> the confliction. > >> > >> I'm not sure I understand here. Within the deployment directory is a > >> set of directories for each RPM architecture. Are you saying that we > >> can get two packages that have different contents but the same RPM > architecture? > >> > > > > Yes, for example the netbase recipe, which the PACKAGE_ARCH = > MACHINE_ARCH. > > Both the normal version of netbase package and the lib32 version are > > named as "netbase-4.45-r1.qemux86_64.rpm" putting in > > tmp/deploy/rpm/qemux86-64 directory, so we need to differentiate them. > > Wow, that is very broken. I think part of the problem is that the arch is > used to > signify not only ABI (and optimizations), but also machine type in this case. > > What we really need is an additional architecture type that handles machine > specific packages for each multilib type. I'm really not sure what they would > be called or how it would work though. > > Anyone have suggestions for naming and processing of these? (I'm almost > tempted to say "machine_lib")
In the weekend I had a talk with Richard and he suggested on adding MLPREFIX to MACHINE_ARCH to differentiate them. Otherwise user need to define a new value for MACHINE_virtclass-multilib-lib32? Thanks, Dongxiao > > --Mark > > > Thanks, > > Dongxiao > > > >> Can you give me an example of what is going wrong? > >> > >> --Mark > >> > >>> Signed-off-by: Dongxiao Xu <[email protected]> > >>> --- > >>> meta/classes/multilib.bbclass | 5 +++++ > >>> meta/classes/rootfs_rpm.bbclass | 4 +++- > >>> 2 files changed, 8 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/meta/classes/multilib.bbclass > >>> b/meta/classes/multilib.bbclass index 76c86b2..6ace1fe 100644 > >>> --- a/meta/classes/multilib.bbclass > >>> +++ b/meta/classes/multilib.bbclass > >>> @@ -77,4 +77,9 @@ python __anonymous () { > >>> multilib_map_variable("PACKAGES_DYNAMIC", variant, d) > >>> multilib_map_variable("PACKAGE_INSTALL", variant, d) > >>> multilib_map_variable("INITSCRIPT_PACKAGES", variant, d) > >>> + > >>> + package_arch = d.getVar("PACKAGE_ARCH", True) > >>> + machine_arch = d.getVar("MACHINE_ARCH", True) > >>> + if package_arch == machine_arch: > >>> + d.setVar("PACKAGE_ARCH", variant + "_" + package_arch) > >>> } > >>> diff --git a/meta/classes/rootfs_rpm.bbclass > >>> b/meta/classes/rootfs_rpm.bbclass index 135ca75..7936d77 100644 > >>> --- a/meta/classes/rootfs_rpm.bbclass > >>> +++ b/meta/classes/rootfs_rpm.bbclass > >>> @@ -218,7 +218,9 @@ python () { > >>> default_tune = > >> localdata.getVar("DEFAULTTUNE_virtclass-multilib-" + eext[1], False) > >>> if default_tune: > >>> localdata.setVar("DEFAULTTUNE", default_tune) > >>> - ml_package_archs += localdata.getVar("PACKAGE_ARCHS", > >> True) or "" > >>> + localdata.setVar("MACHINE_ARCH", eext[1] + "_" + > >> localdata.getVar("MACHINE_ARCH", False)) > >>> + package_archs = localdata.getVar("PACKAGE_ARCHS", > True) > >> or "" > >>> + ml_package_archs += " " + package_archs > >>> #bb.note("ML_PACKAGE_ARCHS %s %s %s" % (eext[1], > >> localdata.getVar("PACKAGE_ARCHS", True) or "(none)", overrides)) > >>> bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, > >> d) } > >> > >> > >> _______________________________________________ > >> Openembedded-core mailing list > >> [email protected] > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > _______________________________________________ > > Openembedded-core mailing list > > [email protected] > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
