[OE-core] [PATCH] gcc-common.inc: Consider multilib when renaming libgcc for debian'ness

[Richard Purdie]

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.khem at 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