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

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

[Khem Raj]

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@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"
 
 MIRRORS =+ "\
 ${GNU_MIRROR}/gcc    ftp://gcc.gnu.org/pub/gcc/releases/ \n \
-- 
1.7.9.5

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

[Richard Purdie]

On Mon, 2012-09-24 at 15:24 -0700, 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@gmail.com>
> ---
>  meta/recipes-devtools/gcc/gcc-common.inc |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Merged to master, thanks.

Richard

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

[McClintock Matthew-B29882]

This should probably go in denzil as well.

-M

On Tue, Sep 25, 2012 at 4:42 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2012-09-24 at 15:24 -0700, 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@gmail.com>
>> ---
>>  meta/recipes-devtools/gcc/gcc-common.inc |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Merged to master, thanks.
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

[Mark Hatle]

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@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 \
>

Re: [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@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

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

[Richard Purdie]

On Tue, 2012-09-25 at 18:07 +0000, McClintock Matthew-B29882 wrote:
> This should probably go in denzil as well.

Lets hold off that as I think we need to fix this in a better way at the
core level...

Cheers,

Richard

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

[McClintock Matthew-B29882]

On Wed, Sep 26, 2012 at 5:55 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2012-09-25 at 18:07 +0000, McClintock Matthew-B29882 wrote:
>> This should probably go in denzil as well.
>
> Lets hold off that as I think we need to fix this in a better way at the
> core level...

This? Where there follow up fixes also?

-M

commit 42e8c8056719326b68b1602e0699eba00a924d2b
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Wed Sep 26 12:56:58 2012 +0100

    packagedata/multilib: Fix search patch for multilib builds

    The current multilib search path code for packagedata is flawed since it
    doesn't correctly handle changes in the TARGET_VENDOR/TARGET_OS that
    multilib may make. This patch enhances the code to correctly build the
    search paths so multilib packagedata is found correctly.

    (From OE-Core rev: f50c5d36b2da9b36d56d95a7d89404509a1a3e9b)

    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core