toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
PATCH 1/1 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
This patch eliminates the long "depends on" lines in toolchain/gcc/Config.in by letting architectures specify from which GCC version the architecture is supported.
Architectures that support only one specific version of GCC should bypass the GCC version selection mechanism.
--- arch/Config.in.arm | 6 ++++ arch/Config.in.powerpc | 7 ++++ arch/Config.in.x86 | 1 + toolchain/gcc/Config.in | 73 +++++++++++++++++++++++++++++++++------------- 4 files changed, 66 insertions(+), 21 deletions(-)
arch/Config.in.arm +6 -0
@@ -36,19 +36,25 @@ config BR2_arm1176jzf_s config BR2_cortex_a5 bool "cortex-A5" select BR2_ARM_CPU_MAYBE_HAS_NEON + select BR2_ARCH_HAS_GCC_4_5_PLUS config BR2_cortex_a8 bool "cortex-A8" select BR2_ARM_CPU_HAS_NEON + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_cortex_a9 bool "cortex-A9" select BR2_ARM_CPU_MAYBE_HAS_NEON + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_cortex_a15 bool "cortex-A15" select BR2_ARM_CPU_HAS_NEON + select BR2_ARCH_HAS_GCC_4_6_PLUS config BR2_fa526 bool "fa526/626" + select BR2_ARCH_HAS_GCC_4_6_PLUS config BR2_pj4 bool "pj4" + select BR2_ARCH_HAS_GCC_4_8_PLUS config BR2_strongarm bool "strongarm sa110/sa1100" config BR2_xscale
arch/Config.in.powerpc +7 -0
@@ -20,12 +20,16 @@ config BR2_powerpc_440fp bool "440 with FPU" config BR2_powerpc_464 bool "464" + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_powerpc_464fp bool "464 with FPU" + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_powerpc_476 bool "476" + select BR2_ARCH_HAS_GCC_4_5_PLUS config BR2_powerpc_476fp bool "476 with FPU" + select BR2_ARCH_HAS_GCC_4_5_PLUS config BR2_powerpc_505 bool "505" config BR2_powerpc_601
@@ -66,10 +70,13 @@ config BR2_powerpc_8548 bool "8548 / e500v2" config BR2_powerpc_e300c2 bool "e300c2" + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_powerpc_e300c3 bool "e300c3" + select BR2_ARCH_HAS_GCC_4_4_PLUS config BR2_powerpc_e500mc bool "e500mc" + select BR2_ARCH_HAS_GCC_4_4_PLUS endchoice choice
arch/Config.in.x86 +1 -0
@@ -86,6 +86,7 @@ config BR2_x86_atom select BR2_X86_CPU_HAS_SSE2 select BR2_X86_CPU_HAS_SSE3 select BR2_X86_CPU_HAS_SSSE3 + select BR2_ARCH_HAS_GCC_4_5_PLUS config BR2_x86_k6 bool "k6" select BR2_X86_CPU_HAS_MMX
toolchain/gcc/Config.in +52 -21
118 lines not on this page · raw message
Signature · 1 line
1.7.0.4
PATCH 1/1 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
Quoted 7 lines · Mischa Jonker
This patch eliminates the long "depends on" lines in toolchain/gcc/Config.in by letting architectures specify from which GCC version the architecture is supported.
Architectures that support only one specific version of GCC should bypass the GCC version selection mechanism.
Quoted 7 lines
Signed-off-by Mischa Jonker<[email protected]>--- arch/Config.in.arm | 6 ++++ arch/Config.in.powerpc | 7 ++++ arch/Config.in.x86 | 1 + toolchain/gcc/Config.in | 73 +++++++++++++++++++++++++++++++++------------- 4 files changed, 66 insertions(+), 21 deletions(-)
Now this looks good! If the 'depends on' statements had been split up
into one line per architecture, the - would have been bigger than the +! So this gets my
I'm not very excited about the sparcleon situation. But perhaps that
architecture can be deprecated? It's not even in our autobuilders AFAIK.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/1 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
Dear Arnout Vandecappelle,
Quoted 2 lines · Arnout Vandecappelle
I'm not very excited about the sparcleon situation. But perhaps that
architecture can be deprecated? It's not even in our autobuilders AFAIK.
I think we had one guy interested in the SPARC Leon support. I remember proposing to remove SPARC support entirely, and one person stepped up to say that he was using SPARC Leon stuff. See
http://lists.busybox.net/pipermail/buildroot/2010-July/036382.html.
I don't think Sam ever sent any patch related to SPARC support.
However, Konrad Eisele sent a bunch of SPARC related patches. However, the last SPARC-related patches Konrad has sent have been sent on November 2010. He later sent some other patches (November 2011), but they were kconfig related, and were extensions to the kconfig language, something we're not ready to accept if they are not part of the upstream kconfig code in the Linux kernel.
I've added Sam and Konrad in Cc to see if they are still using SPARC support, and whether it's worth adding a sparc sample to our autobuilders.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
Hi Sam, Konrad,
Quoted 21 lines · Thomas Petazzoni
Dear Arnout Vandecappelle,
Quoted 2 lines · Arnout Vandecappelle
I'm not very excited about the sparcleon situation. But perhaps that
architecture can be deprecated? It's not even in our autobuilders AFAIK.I think we had one guy interested in the SPARC Leon support. I remember proposing to remove SPARC support entirely, and one person stepped up to say that he was using SPARC Leon stuff. See
http://lists.busybox.net/pipermail/buildroot/2010-July/036382.html.I don't think Sam ever sent any patch related to SPARC support.
However, Konrad Eisele sent a bunch of SPARC related patches. However, the last SPARC-related patches Konrad has sent have been sent on November 2010. He later sent some other patches (November 2011), but they were kconfig related, and were extensions to the kconfig language, something we're not ready to accept if they are not part of the upstream kconfig code in the Linux kernel.
Quoted 3 lines
I've added Sam and Konrad in Cc to see if they are still using SPARC support, and whether it's worth adding a sparc sample to our autobuilders.
I'm reviving this older thread.
Are any of you still interested in SPARC support in buildroot (see above) ?
Thanks,
Thomas
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
Quoted 45 lines · Sam Ravnborg
Quoted 25 lines · Thomas De Schampheleire
Hi Sam, Konrad,
Quoted 21 lines · Thomas Petazzoni
Dear Arnout Vandecappelle,
Quoted 2 lines · Arnout Vandecappelle
I'm not very excited about the sparcleon situation. But perhaps that
architecture can be deprecated? It's not even in our autobuilders AFAIK.I think we had one guy interested in the SPARC Leon support. I remember proposing to remove SPARC support entirely, and one person stepped up to say that he was using SPARC Leon stuff. See
http://lists.busybox.net/pipermail/buildroot/2010-July/036382.html.I don't think Sam ever sent any patch related to SPARC support.
However, Konrad Eisele sent a bunch of SPARC related patches. However, the last SPARC-related patches Konrad has sent have been sent on November 2010. He later sent some other patches (November 2011), but they were kconfig related, and were extensions to the kconfig language, something we're not ready to accept if they are not part of the upstream kconfig code in the Linux kernel.
Quoted 6 lines
Quoted 3 lines
I've added Sam and Konrad in Cc to see if they are still using SPARC support, and whether it's worth adding a sparc sample to our autobuilders.
I'm reviving this older thread.
Are any of you still interested in SPARC support in buildroot (see above) ?My SPARC usage is very basic. I use a toolchain build using crosstoll-ng. I added very basic SPARC support to crosstool-ng for this same purpose.
And then I have used buildroot to create a minimal rootfs that contains busybox and almost nothing else.
I use this rootfs to check that the kernel can boot into user-space. And so far alll effort from my side has been on the kernel side of things, and for that I have used the same rotfs for more than a year.Recently (the last year os so) I have had limited spare time for kernel/sparc activities - so even on the kernel side not much activity has been seen.
Quoted 7 lines
So I cannot say that I can be considered a SPARC user of buildroot, considering the limited effort I can put in these days.
So I would hate it - but you cannot justify keeping SPRC support just because I am hanging around.I have added a few more gaisler people - maybe they can say more about their potential use of buildroot.
Hi!
We, Aeroflex Gaisler, and customers of ours are actively using buildrot. Our Linux build environment for Leon SPARC systems that we ship to customers are using buildroot. Furthermore, we also have customers that are using buildroot out of the box outside our build environment.
So dropping SPARC support for buildroot would be a very bad thing.
Thanks Sam for cc:ing some more Aeroflex Gaisler people.
Best Regards,
Andreas Larsson
PATCH 1/1 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
In reply to a message not in the archiveQuoted 45 lines · Sam Ravnborg
Quoted 25 lines · Thomas De Schampheleire
Hi Sam, Konrad,
Quoted 21 lines · Thomas Petazzoni
Dear Arnout Vandecappelle,
Quoted 2 lines · Arnout Vandecappelle
I'm not very excited about the sparcleon situation. But perhaps that
architecture can be deprecated? It's not even in our autobuilders AFAIK.I think we had one guy interested in the SPARC Leon support. I remember proposing to remove SPARC support entirely, and one person stepped up to say that he was using SPARC Leon stuff. See
http://lists.busybox.net/pipermail/buildroot/2010-July/036382.html.I don't think Sam ever sent any patch related to SPARC support.
However, Konrad Eisele sent a bunch of SPARC related patches. However, the last SPARC-related patches Konrad has sent have been sent on November 2010. He later sent some other patches (November 2011), but they were kconfig related, and were extensions to the kconfig language, something we're not ready to accept if they are not part of the upstream kconfig code in the Linux kernel.
Quoted 6 lines
Quoted 3 lines
I've added Sam and Konrad in Cc to see if they are still using SPARC support, and whether it's worth adding a sparc sample to our autobuilders.
I'm reviving this older thread.
Are any of you still interested in SPARC support in buildroot (see above) ?My SPARC usage is very basic. I use a toolchain build using crosstoll-ng. I added very basic SPARC support to crosstool-ng for this same purpose.
And then I have used buildroot to create a minimal rootfs that contains busybox and almost nothing else.
I use this rootfs to check that the kernel can boot into user-space. And so far alll effort from my side has been on the kernel side of things, and for that I have used the same rotfs for more than a year.Recently (the last year os so) I have had limited spare time for kernel/sparc activities - so even on the kernel side not much activity has been seen.
Quoted 7 lines
So I cannot say that I can be considered a SPARC user of buildroot, considering the limited effort I can put in these days.
So I would hate it - but you cannot justify keeping SPRC support just because I am hanging around.I have added a few more gaisler people - maybe they can say more about their potential use of buildroot.
[Resending, as my first answer got stuck in moderation queue due to too many people in cc]
Hi!
We, Aeroflex Gaisler, and customers of ours are actively using buildrot. Our Linux build environment for Leon SPARC systems that we ship to customers are using buildroot. Furthermore, we also have customers that are using buildroot out of the box outside our build environment.
So dropping SPARC support for buildroot would be a very bad thing.
Thanks Sam for cc:ing some more Aeroflex Gaisler people.
Best Regards,
Andreas Larsson
PATCH 1/1 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
In reply to Arnout VandecappelleHi,
Quoted 19 lines · Arnout Vandecappelle
Quoted 8 lines · Mischa Jonker
This patch eliminates the long "depends on" lines in toolchain/gcc/Config.in by letting architectures specify from which GCC version the architecture is supported.
Architectures that support only one specific version of GCC should bypass the GCC version selection mechanism.
Quoted 8 lines
Signed-off-by Mischa Jonker<[email protected]>--- arch/Config.in.arm | 6 ++++ arch/Config.in.powerpc | 7 ++++ arch/Config.in.x86 | 1 + toolchain/gcc/Config.in | 73 +++++++++++++++++++++++++++++++++------------- 4 files changed, 66 insertions(+), 21 deletions(-)
Quoted 7 lines
Now this looks good! If the 'depends on' statements had been split up into
one line per architecture, the - would have been bigger than the +! So this gets my
This patch has been lying around for a while. It will need to be updated a bit because e.g. the gcc package has moved, but other than that are there reasons not to include it?
Best regards,
Thomas