On Tue, 2012-09-25 at 13:12 -0500, Mark Hatle wrote: > On 9/24/12 5:24 PM, Khem Raj wrote: > > When doing multilib builds rpm does not find libgcc1 for lib32 > > multilib because its not honoring the debian renaming scheme for > > libgcc-multilib. Lets add MLPREFIX to fix it. > > > > Signed-off-by: Khem Raj <raj.k...@gmail.com> > > --- > > meta/recipes-devtools/gcc/gcc-common.inc | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/meta/recipes-devtools/gcc/gcc-common.inc > > b/meta/recipes-devtools/gcc/gcc-common.inc > > index 3b00017..38f3b7f 100644 > > --- a/meta/recipes-devtools/gcc/gcc-common.inc > > +++ b/meta/recipes-devtools/gcc/gcc-common.inc > > @@ -40,7 +40,7 @@ def get_gcc_multiarch_setting(bb, d): > > # For now, libgcc is most important so we fix for that - RP. > > SHLIBSDIR = "${STAGING_DIR_TARGET}/shlibs" > > > > -DEBIANNAME_libgcc = "libgcc1" > > +DEBIANNAME_${MLPREFIX}libgcc = "libgcc1" > > I realize this is a fairly rare case, but should the debian (or multilib) > bbclasses be multilib aware, and if so automatically generate the > corresponding > DEBIANNAME_${MLPREFIX}pn = value? > > This is already done for blacklists, preferred provider/version and > whitelists > in the base.bbclass. Then if anyone (in the future) specifies DEBIANNAME, > it'll > be automatic.
The multilib/package code does have a list of variables it processes for this, this one should probably be added to that list. In fact debian.bbclass should append it to the list package.bbclass has... Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core