Patchwork gcc-common.inc: Consider multilib when renaming libgcc for debian'ness

login
register
mail settings
Submitter Khem Raj
Date Sept. 24, 2012, 10:24 p.m.
Message ID <1348525482-31986-1-git-send-email-raj.khem@gmail.com>
Download mbox | patch
Permalink /patch/37149/
State Accepted
Commit 9327ca868667b15f29af3123611d6f56b4249a63
Headers show

Comments

Khem Raj - Sept. 24, 2012, 10:24 p.m.
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(-)
Richard Purdie - Sept. 25, 2012, 9:42 a.m.
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
McClintock Matthew-B29882 - Sept. 25, 2012, 6:07 p.m.
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
Mark Hatle - Sept. 25, 2012, 6:12 p.m.
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 \
>
Richard Purdie - Sept. 25, 2012, 9:53 p.m.
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
Richard Purdie - Sept. 26, 2012, 10:55 a.m.
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
McClintock Matthew-B29882 - Sept. 28, 2012, 6:31 p.m.
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

Patch

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 \