Patchwork [v3] Introduce multiarch DISTRO_FEATURE

login
register
mail settings
Submitter Julian Pidancet
Date Nov. 25, 2011, 12:29 p.m.
Message ID <5ca10bdeed6e90862311b8417c0e6de353d1dc70.1322223227.git.julian.pidancet@gmail.com>
Download mbox | patch
Permalink /patch/15425/
State New
Headers show

Comments

Julian Pidancet - Nov. 25, 2011, 12:29 p.m.
This patch introduces a distro feature which enables gcc to produce
both 32bit and 64bit code, and enables binutils to operate on both
32bit and 64bit binaries.

v3: - Make get_gcc_multiarch_setting more elegant. Use a dictionnary
to store the config options and replace bb.data.getVar with d.getVar.
    - Remove i686 from the architecture list because it doesn't seem
to be a valid TARGET_ARCH any more in OE.
    - Configure gdb (gdb and gdb-cross) with --enable-64-bit-bfd if
multiarch DISTRO_FEATURE is present

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
---
 meta/recipes-devtools/binutils/binutils-cross.inc  |    3 ++-
 meta/recipes-devtools/binutils/binutils.inc        |    3 ++-
 meta/recipes-devtools/gcc/gcc-common.inc           |   13 +++++++++++++
 meta/recipes-devtools/gcc/gcc-configure-common.inc |    3 ++-
 meta/recipes-devtools/gdb/gdb-common.inc           |    1 +
 5 files changed, 20 insertions(+), 3 deletions(-)
McClintock Matthew-B29882 - Nov. 25, 2011, 7:07 p.m.
On Fri, Nov 25, 2011 at 6:29 AM, Julian Pidancet
<julian.pidancet@gmail.com> wrote:
> This patch introduces a distro feature which enables gcc to produce
> both 32bit and 64bit code, and enables binutils to operate on both
> 32bit and 64bit binaries.
>
> v3: - Make get_gcc_multiarch_setting more elegant. Use a dictionnary
> to store the config options and replace bb.data.getVar with d.getVar.
>    - Remove i686 from the architecture list because it doesn't seem
> to be a valid TARGET_ARCH any more in OE.
>    - Configure gdb (gdb and gdb-cross) with --enable-64-bit-bfd if
> multiarch DISTRO_FEATURE is present
>
> Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>

I'm not sure if this is the correct spot to bring this up, but how
should we go about building a 32-bit and 64-bit libgcc?

-M
Richard Purdie - Nov. 25, 2011, 11:40 p.m.
On Fri, 2011-11-25 at 19:07 +0000, McClintock Matthew-B29882 wrote:
> On Fri, Nov 25, 2011 at 6:29 AM, Julian Pidancet
> <julian.pidancet@gmail.com> wrote:
> > This patch introduces a distro feature which enables gcc to produce
> > both 32bit and 64bit code, and enables binutils to operate on both
> > 32bit and 64bit binaries.
> >
> > v3: - Make get_gcc_multiarch_setting more elegant. Use a dictionnary
> > to store the config options and replace bb.data.getVar with d.getVar.
> >    - Remove i686 from the architecture list because it doesn't seem
> > to be a valid TARGET_ARCH any more in OE.
> >    - Configure gdb (gdb and gdb-cross) with --enable-64-bit-bfd if
> > multiarch DISTRO_FEATURE is present
> >
> > Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
> 
> I'm not sure if this is the correct spot to bring this up, but how
> should we go about building a 32-bit and 64-bit libgcc?

This is firmly in multilib territory as its not just libgcc but libc as
well and so it goes on.

One of the reasons I'm nervous of the patch you're replying to is that
people are now going to try and cross the two and we'll end up with a
mess :(.

Trying to build just libgcc from the gcc tree is a nightmare and when we
last tried it, caused no end of problems.

What specific problem are you trying to solve?

Cheers,

Richard
McClintock Matthew-B29882 - Nov. 28, 2011, 9:32 p.m.
On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> This is firmly in multilib territory as its not just libgcc but libc as
> well and so it goes on.
>
> One of the reasons I'm nervous of the patch you're replying to is that
> people are now going to try and cross the two and we'll end up with a
> mess :(.
>
> Trying to build just libgcc from the gcc tree is a nightmare and when we
> last tried it, caused no end of problems.
>
> What specific problem are you trying to solve?

The specific issue I'm having is for our 64-bit part that still uses a
32-bit u-boot. Not sure the best approach really is...

I've tried utilizing multilib by adding the following to my u-boot
recipe, but it's just hacky...

DEPENDS_e5500-64b_append = " lib32-gcc"
CC_e5500-64b = "powerpc-poky-linux-gcc -m32"

I'd rather NOT recompile gcc/eglibc/etc just for this 32-bit build of
u-boot where we don't need libc. I'd rather just have a functional
32bit/64bit compiler for our 64-bit target.

Looking forward farther, I would like to have one toolchain
("meta-toolchain") that can produce target code for multiple targets
also.

-M
Julian Pidancet - Nov. 28, 2011, 10:14 p.m.
On Mon, Nov 28, 2011 at 9:32 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> This is firmly in multilib territory as its not just libgcc but libc as
>> well and so it goes on.
>>
>> One of the reasons I'm nervous of the patch you're replying to is that
>> people are now going to try and cross the two and we'll end up with a
>> mess :(.
>>
>> Trying to build just libgcc from the gcc tree is a nightmare and when we
>> last tried it, caused no end of problems.
>>
>> What specific problem are you trying to solve?
>
> The specific issue I'm having is for our 64-bit part that still uses a
> 32-bit u-boot. Not sure the best approach really is...
>
> I've tried utilizing multilib by adding the following to my u-boot
> recipe, but it's just hacky...
>
> DEPENDS_e5500-64b_append = " lib32-gcc"
> CC_e5500-64b = "powerpc-poky-linux-gcc -m32"
>
> I'd rather NOT recompile gcc/eglibc/etc just for this 32-bit build of
> u-boot where we don't need libc. I'd rather just have a functional
> 32bit/64bit compiler for our 64-bit target.
>
> Looking forward farther, I would like to have one toolchain
> ("meta-toolchain") that can produce target code for multiple targets
> also.
>

Does u-boot really need to compile against libgcc ? I'm just curious.

Unfortunately I believe that producing one libgcc per bit format is a
multilib use-case, not a bi-arch use-case.

Richard, regarding your concerns about people mixing up bi-arch and
multilib. Isn't there any way we could make these two things mutually
exclusive ?
Khem Raj - Nov. 28, 2011, 10:22 p.m.
On Mon, Nov 28, 2011 at 2:14 PM, Julian Pidancet
<julian.pidancet@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 9:32 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> This is firmly in multilib territory as its not just libgcc but libc as
>>> well and so it goes on.
>>>
>>> One of the reasons I'm nervous of the patch you're replying to is that
>>> people are now going to try and cross the two and we'll end up with a
>>> mess :(.
>>>
>>> Trying to build just libgcc from the gcc tree is a nightmare and when we
>>> last tried it, caused no end of problems.
>>>
>>> What specific problem are you trying to solve?
>>
>> The specific issue I'm having is for our 64-bit part that still uses a
>> 32-bit u-boot. Not sure the best approach really is...
>>
>> I've tried utilizing multilib by adding the following to my u-boot
>> recipe, but it's just hacky...
>>
>> DEPENDS_e5500-64b_append = " lib32-gcc"
>> CC_e5500-64b = "powerpc-poky-linux-gcc -m32"
>>
>> I'd rather NOT recompile gcc/eglibc/etc just for this 32-bit build of
>> u-boot where we don't need libc. I'd rather just have a functional
>> 32bit/64bit compiler for our 64-bit target.
>>
>> Looking forward farther, I would like to have one toolchain
>> ("meta-toolchain") that can produce target code for multiple targets
>> also.
>>
>
> Does u-boot really need to compile against libgcc ? I'm just curious.
>
> Unfortunately I believe that producing one libgcc per bit format is a
> multilib use-case, not a bi-arch use-case.
>
> Richard, regarding your concerns about people mixing up bi-arch and
> multilib. Isn't there any way we could make these two things mutually
> exclusive ?

I think we should make it inclusive
ideally we should have bi-arch/tri-arch toolchain building multilib userspace.
in which case we have single compiler for multilib as well as archness
McClintock Matthew-B29882 - Nov. 28, 2011, 10:24 p.m.
On Mon, Nov 28, 2011 at 4:22 PM, Khem Raj <raj.khem@gmail.com> wrote:
> I think we should make it inclusive
> ideally we should have bi-arch/tri-arch toolchain building multilib userspace.
> in which case we have single compiler for multilib as well as archness

I would like to see this as well.

-M
Richard Purdie - Nov. 28, 2011, 10:56 p.m.
On Mon, 2011-11-28 at 21:32 +0000, McClintock Matthew-B29882 wrote:
> On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
> > What specific problem are you trying to solve?
> 
> The specific issue I'm having is for our 64-bit part that still uses a
> 32-bit u-boot. Not sure the best approach really is...

Hmm, does it really need libgcc?

> I've tried utilizing multilib by adding the following to my u-boot
> recipe, but it's just hacky...
> 
> DEPENDS_e5500-64b_append = " lib32-gcc"
> CC_e5500-64b = "powerpc-poky-linux-gcc -m32"
> 
> I'd rather NOT recompile gcc/eglibc/etc just for this 32-bit build of
> u-boot where we don't need libc. I'd rather just have a functional
> 32bit/64bit compiler for our 64-bit target.

The trouble is that you need glibc-intermediate to build gcc-cross
(which builds a functional libgcc). You therefore can't short circuit
this as much as you think :/.

> Looking forward farther, I would like to have one toolchain
> ("meta-toolchain") that can produce target code for multiple targets
> also.

This is easier since we would just add lib32-gcc and lib-gcc to the
sysroot. It then becomes a case of just ensuring gcc is configured
correctly.

Cheers,

Richard
McClintock Matthew-B29882 - Nov. 28, 2011, 11 p.m.
On Mon, Nov 28, 2011 at 4:56 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2011-11-28 at 21:32 +0000, McClintock Matthew-B29882 wrote:
>> On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
>> > What specific problem are you trying to solve?
>>
>> The specific issue I'm having is for our 64-bit part that still uses a
>> 32-bit u-boot. Not sure the best approach really is...
>
> Hmm, does it really need libgcc?

I pretty sure... I don't think it uses much though.

>
>> I've tried utilizing multilib by adding the following to my u-boot
>> recipe, but it's just hacky...
>>
>> DEPENDS_e5500-64b_append = " lib32-gcc"
>> CC_e5500-64b = "powerpc-poky-linux-gcc -m32"
>>
>> I'd rather NOT recompile gcc/eglibc/etc just for this 32-bit build of
>> u-boot where we don't need libc. I'd rather just have a functional
>> 32bit/64bit compiler for our 64-bit target.
>
> The trouble is that you need glibc-intermediate to build gcc-cross
> (which builds a functional libgcc). You therefore can't short circuit
> this as much as you think :/.

Is there a way to skip eglibc then? That would make things much better.

-M
Richard Purdie - Nov. 29, 2011, 12:30 p.m.
On Mon, 2011-11-28 at 23:00 +0000, McClintock Matthew-B29882 wrote:
> On Mon, Nov 28, 2011 at 4:56 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Mon, 2011-11-28 at 21:32 +0000, McClintock Matthew-B29882 wrote:
> >> On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
> >> > What specific problem are you trying to solve?
> >>
> >> The specific issue I'm having is for our 64-bit part that still uses a
> >> 32-bit u-boot. Not sure the best approach really is...
> >
> > Hmm, does it really need libgcc?
> 
> I pretty sure... I don't think it uses much though.
> 
> >
> >> I've tried utilizing multilib by adding the following to my u-boot
> >> recipe, but it's just hacky...
> >>
> >> DEPENDS_e5500-64b_append = " lib32-gcc"
> >> CC_e5500-64b = "powerpc-poky-linux-gcc -m32"
> >>
> >> I'd rather NOT recompile gcc/eglibc/etc just for this 32-bit build of
> >> u-boot where we don't need libc. I'd rather just have a functional
> >> 32bit/64bit compiler for our 64-bit target.
> >
> > The trouble is that you need glibc-intermediate to build gcc-cross
> > (which builds a functional libgcc). You therefore can't short circuit
> > this as much as you think :/.
> 
> Is there a way to skip eglibc then? That would make things much better.

If you depend just on lib32-libgcc:do_populate_sysroot, it shouldn't
build eglibc. You can do that with something like:

do_compile[depends] += "lib32-libgcc:do_populate_sysroot"

Cheers,

Richard
Saul Wold - Nov. 29, 2011, 3:48 p.m.
On 11/25/2011 04:29 AM, Julian Pidancet wrote:
> This patch introduces a distro feature which enables gcc to produce
> both 32bit and 64bit code, and enables binutils to operate on both
> 32bit and 64bit binaries.
>
> v3: - Make get_gcc_multiarch_setting more elegant. Use a dictionnary
> to store the config options and replace bb.data.getVar with d.getVar.
>      - Remove i686 from the architecture list because it doesn't seem
> to be a valid TARGET_ARCH any more in OE.
>      - Configure gdb (gdb and gdb-cross) with --enable-64-bit-bfd if
> multiarch DISTRO_FEATURE is present
>
> Signed-off-by: Julian Pidancet<julian.pidancet@gmail.com>
> ---
>   meta/recipes-devtools/binutils/binutils-cross.inc  |    3 ++-
>   meta/recipes-devtools/binutils/binutils.inc        |    3 ++-
>   meta/recipes-devtools/gcc/gcc-common.inc           |   13 +++++++++++++
>   meta/recipes-devtools/gcc/gcc-configure-common.inc |    3 ++-
>   meta/recipes-devtools/gdb/gdb-common.inc           |    1 +
>   5 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-devtools/binutils/binutils-cross.inc b/meta/recipes-devtools/binutils/binutils-cross.inc
> index 982224f..f07907e 100644
> --- a/meta/recipes-devtools/binutils/binutils-cross.inc
> +++ b/meta/recipes-devtools/binutils/binutils-cross.inc
> @@ -10,7 +10,8 @@ EXTRA_OECONF = "--with-sysroot=${STAGING_DIR_TARGET} \
>                   --disable-werror \
>                   --disable-nls \
>                   --enable-poison-system-directories \
> -		${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default', '', d)}"
> +                ${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default', '', d)} \
> +                ${@base_contains('DISTRO_FEATURES', 'multiarch', '--enable-64-bit-bfd', '', d)}"
>
>   do_install () {
>   	oe_runmake 'DESTDIR=${D}' install
> diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
> index 58fee85..51e4257 100644
> --- a/meta/recipes-devtools/binutils/binutils.inc
> +++ b/meta/recipes-devtools/binutils/binutils.inc
> @@ -49,7 +49,8 @@ B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"
>
>   EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \
>                   --enable-install-libbfd \
> -                --enable-shared"
> +                --enable-shared \
> +                ${@base_contains('DISTRO_FEATURES', 'multiarch', '--enable-64-bit-bfd', '', d)}"
>
>   EXTRA_OECONF_virtclass-native = "--enable-target=all --enable-64-bit-bfd --enable-install-libbfd"
>
> diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
> index 69e0213..fe112d9 100644
> --- a/meta/recipes-devtools/gcc/gcc-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-common.inc
> @@ -21,6 +21,19 @@ def get_gcc_mips_plt_setting(bb, d):
>           return "--with-mips-plt"
>       return ""
>
> +def get_gcc_multiarch_setting(bb, d):
> +    target_arch = d.getVar('TARGET_ARCH', True)
> +    multiarch_options = {
> +        "i586":    "--enable-targets=all",
> +        "powerpc": "--enable-targets=powerpc64",
> +        "sparc":   "--enable-targets=all",
> +    }
> +
> +    if 'multiarch' in d.getVar('DISTRO_FEATURES', True).split() :
> +        if target_arch in multiarch_options :
> +            return multiarch_options[target_arch]
> +    return ""
> +
>   # We really need HOST_SYS here for some packages and TARGET_SYS for others.
>   # For now, libgcc is most important so we fix for that - RP.
>   SHLIBSDIR = "${STAGING_DIR_TARGET}/shlibs"
> diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> index ae23e8e..d014980 100644
> --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> @@ -42,7 +42,8 @@ EXTRA_OECONF = "${@['--enable-clocale=generic', ''][d.getVar('USE_NLS', 1) != 'n
>                   ${EXTRA_OECONF_BASE} \
>                   ${EXTRA_OECONF_FPU} \
>                   ${EXTRA_OECONF_PATHS} \
> -                ${@get_gcc_mips_plt_setting(bb, d)}"
> +                ${@get_gcc_mips_plt_setting(bb, d)} \
> +                ${@get_gcc_multiarch_setting(bb, d)}"
>
>   # Build uclibc compilers without cxa_atexit support
>   EXTRA_OECONF_append_linux               = " --enable-__cxa_atexit"
> diff --git a/meta/recipes-devtools/gdb/gdb-common.inc b/meta/recipes-devtools/gdb/gdb-common.inc
> index e01b57c..d728139 100644
> --- a/meta/recipes-devtools/gdb/gdb-common.inc
> +++ b/meta/recipes-devtools/gdb/gdb-common.inc
> @@ -41,6 +41,7 @@ EXPAT = "--without-expat"
>   EXTRA_OECONF = "--disable-gdbtk --disable-tui --disable-x \
>                   --with-curses --disable-multilib --with-system-readline --disable-sim \
>                   ${GDBPROPREFIX} --with-libelf=${STAGING_DIR_TARGET} ${EXPAT} \
> +                ${@base_contains('DISTRO_FEATURES', 'multiarch', '--enable-64-bit-bfd', '', d)} \
>                  "
>
>   GDBPROPREFIX = "--program-prefix=''"


Julian,

Thanks for your patience, this is merged into OE-Core

Thanks
	Sau!
Julian Pidancet - Nov. 29, 2011, 3:58 p.m.
On Tue, Nov 29, 2011 at 3:48 PM, Saul Wold <sgw@linux.intel.com> wrote:
>
> Julian,
>
> Thanks for your patience, this is merged into OE-Core
>
> Thanks
>        Sau!
>

Saul, I believe you applied the wrong version of the patch.
According to:
http://git.openembedded.org/openembedded-core/commit/?id=99e295ef30ba02db3966c66619807c037ef5089f

This is v2 instead of v3.
McClintock Matthew-B29882 - Nov. 29, 2011, 4:10 p.m.
On Tue, Nov 29, 2011 at 6:30 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> If you depend just on lib32-libgcc:do_populate_sysroot, it shouldn't
> build eglibc. You can do that with something like:
>
> do_compile[depends] += "lib32-libgcc:do_populate_sysroot"

Thanks, I'll give this a try.

-M
McClintock Matthew-B29882 - Nov. 29, 2011, 9:48 p.m.
On Tue, Nov 29, 2011 at 10:10 AM, Matthew McClintock <msm@freescale.com> wrote:
> On Tue, Nov 29, 2011 at 6:30 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> If you depend just on lib32-libgcc:do_populate_sysroot, it shouldn't
>> build eglibc. You can do that with something like:
>>
>> do_compile[depends] += "lib32-libgcc:do_populate_sysroot"
>
> Thanks, I'll give this a try.

This is building some eglibc stuff...

NOTE: package lib32-eglibc-initial-2.13-r15+svnr14157: task
do_populate_sysroot: Succeeded

-M
McClintock Matthew-B29882 - Nov. 30, 2011, 1:05 a.m.
On Tue, Nov 29, 2011 at 3:47 PM, Matthew McClintock <msm@freescale.com> wrote:
> On Tue, Nov 29, 2011 at 10:10 AM, Matthew McClintock <msm@freescale.com> wrote:
>> On Tue, Nov 29, 2011 at 6:30 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> If you depend just on lib32-libgcc:do_populate_sysroot, it shouldn't
>>> build eglibc. You can do that with something like:
>>>
>>> do_compile[depends] += "lib32-libgcc:do_populate_sysroot"
>>
>> Thanks, I'll give this a try.
>
> This is building some eglibc stuff...
>
> NOTE: package lib32-eglibc-initial-2.13-r15+svnr14157: task
> do_populate_sysroot: Succeeded

Richard,

Also for u-boot I have:

PACKAGE_ARCH = "${MACHINE}"

Which prevents me from doing 'bitbake lib32-u-boot', I've hacked
around this and gotten a 'bitbake u-boot' to use the multilib compiler
but it's not pretty. Maybe we need an 'inherit multilib' or something
which let's a recipe use a multilib compiler environment?

Also doing a

do_compile[depends] += "lib32-gcc-cross:do_populate_sysroot"

Causes eglibc to get built...

-M

-M
Saul Wold - Nov. 30, 2011, 9:21 p.m.
On 11/29/2011 07:58 AM, Julian Pidancet wrote:
> On Tue, Nov 29, 2011 at 3:48 PM, Saul Wold<sgw@linux.intel.com>  wrote:
>>
>> Julian,
>>
>> Thanks for your patience, this is merged into OE-Core
>>
>> Thanks
>>         Sau!
>>
>
> Saul, I believe you applied the wrong version of the patch.
> According to:
> http://git.openembedded.org/openembedded-core/commit/?id=99e295ef30ba02db3966c66619807c037ef5089f
>
> This is v2 instead of v3.
>
Can you provide an update then, that brings it up to the v3, sorry about 
this, I was managing too many patches this last time.

Thanks
	Sau!

Patch

diff --git a/meta/recipes-devtools/binutils/binutils-cross.inc b/meta/recipes-devtools/binutils/binutils-cross.inc
index 982224f..f07907e 100644
--- a/meta/recipes-devtools/binutils/binutils-cross.inc
+++ b/meta/recipes-devtools/binutils/binutils-cross.inc
@@ -10,7 +10,8 @@  EXTRA_OECONF = "--with-sysroot=${STAGING_DIR_TARGET} \
                 --disable-werror \
                 --disable-nls \
                 --enable-poison-system-directories \
-		${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default', '', d)}"
+                ${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--enable-gold=default', '', d)} \
+                ${@base_contains('DISTRO_FEATURES', 'multiarch', '--enable-64-bit-bfd', '', d)}"
 
 do_install () {
 	oe_runmake 'DESTDIR=${D}' install
diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
index 58fee85..51e4257 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -49,7 +49,8 @@  B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"
 
 EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \
                 --enable-install-libbfd \
-                --enable-shared"
+                --enable-shared \
+                ${@base_contains('DISTRO_FEATURES', 'multiarch', '--enable-64-bit-bfd', '', d)}"
 
 EXTRA_OECONF_virtclass-native = "--enable-target=all --enable-64-bit-bfd --enable-install-libbfd"
 
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
index 69e0213..fe112d9 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -21,6 +21,19 @@  def get_gcc_mips_plt_setting(bb, d):
         return "--with-mips-plt"
     return ""
 
+def get_gcc_multiarch_setting(bb, d):
+    target_arch = d.getVar('TARGET_ARCH', True)
+    multiarch_options = {
+        "i586":    "--enable-targets=all",
+        "powerpc": "--enable-targets=powerpc64",
+        "sparc":   "--enable-targets=all",
+    }
+
+    if 'multiarch' in d.getVar('DISTRO_FEATURES', True).split() :
+        if target_arch in multiarch_options :
+            return multiarch_options[target_arch]
+    return ""
+
 # We really need HOST_SYS here for some packages and TARGET_SYS for others.
 # For now, libgcc is most important so we fix for that - RP.
 SHLIBSDIR = "${STAGING_DIR_TARGET}/shlibs"
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index ae23e8e..d014980 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -42,7 +42,8 @@  EXTRA_OECONF = "${@['--enable-clocale=generic', ''][d.getVar('USE_NLS', 1) != 'n
                 ${EXTRA_OECONF_BASE} \
                 ${EXTRA_OECONF_FPU} \
                 ${EXTRA_OECONF_PATHS} \
-                ${@get_gcc_mips_plt_setting(bb, d)}"
+                ${@get_gcc_mips_plt_setting(bb, d)} \
+                ${@get_gcc_multiarch_setting(bb, d)}"
 
 # Build uclibc compilers without cxa_atexit support
 EXTRA_OECONF_append_linux               = " --enable-__cxa_atexit"
diff --git a/meta/recipes-devtools/gdb/gdb-common.inc b/meta/recipes-devtools/gdb/gdb-common.inc
index e01b57c..d728139 100644
--- a/meta/recipes-devtools/gdb/gdb-common.inc
+++ b/meta/recipes-devtools/gdb/gdb-common.inc
@@ -41,6 +41,7 @@  EXPAT = "--without-expat"
 EXTRA_OECONF = "--disable-gdbtk --disable-tui --disable-x \
                 --with-curses --disable-multilib --with-system-readline --disable-sim \
                 ${GDBPROPREFIX} --with-libelf=${STAGING_DIR_TARGET} ${EXPAT} \
+                ${@base_contains('DISTRO_FEATURES', 'multiarch', '--enable-64-bit-bfd', '', d)} \
                "
 
 GDBPROPREFIX = "--program-prefix=''"