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 <[email protected]>
---
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 \
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
