| 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
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
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
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
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 ?
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
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
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
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
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
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!
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.
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
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
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
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=''"
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(-)