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

Mark Hatle mark.hatle at windriver.com
Tue Sep 25 18:12:01 UTC 2012


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.

--Mark

>   MIRRORS =+ "\
>   ${GNU_MIRROR}/gcc    ftp://gcc.gnu.org/pub/gcc/releases/ \n \
>





More information about the Openembedded-core mailing list