| 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
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
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
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 \ >
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
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
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 \
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(-)