[Buildroot] [PATCH] toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS

[Buildroot] [PATCH] toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS

[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.

Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
---
 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(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 2f4c0c8..fd6671d 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -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
diff --git a/arch/Config.in.powerpc b/arch/Config.in.powerpc
index 8643efc..cd87b7c 100644
--- a/arch/Config.in.powerpc
+++ b/arch/Config.in.powerpc
@@ -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
diff --git a/arch/Config.in.x86 b/arch/Config.in.x86
index ce30605..a7255b6 100644
--- a/arch/Config.in.x86
+++ b/arch/Config.in.x86
@@ -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
diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in
index f297e73..8d7e2e9 100644
--- a/toolchain/gcc/Config.in
+++ b/toolchain/gcc/Config.in
@@ -2,56 +2,83 @@
 
 comment "GCC Options"
 
+config BR2_ARCH_HAS_ALL_GCC
+	bool
+	default y if !(BR2_ARCH_HAS_GCC_4_4_PLUS || \
+		       BR2_ARCH_HAS_GCC_4_5_PLUS || \
+		       BR2_ARCH_HAS_GCC_4_6_PLUS || \
+		       BR2_ARCH_HAS_GCC_4_7_PLUS || \
+		       BR2_ARCH_HAS_GCC_4_8_PLUS || \
+		       BR2_ARCH_HAS_GCC_SNAP_ONLY)
+
+config BR2_ARCH_HAS_GCC_4_4_PLUS
+	bool
+	select BR2_ARCH_HAS_GCC_4_5_PLUS
+
+config BR2_ARCH_HAS_GCC_4_5_PLUS
+	bool
+	select BR2_ARCH_HAS_GCC_4_6_PLUS
+
+config BR2_ARCH_HAS_GCC_4_6_PLUS
+	bool
+	select BR2_ARCH_HAS_GCC_4_7_PLUS
+
+config BR2_ARCH_HAS_GCC_4_7_PLUS
+	bool
+	select BR2_ARCH_HAS_GCC_4_8_PLUS
+
+config BR2_ARCH_HAS_GCC_4_8_PLUS
+	bool
+	select BR2_ARCH_HAS_GCC_SNAP_ONLY
+
+config BR2_ARCH_HAS_GCC_SNAP_ONLY
+	bool
+
 config BR2_GCC_NEEDS_MPC
 	bool
 
 choice
 	prompt "GCC compiler Version"
-	default BR2_GCC_VERSION_4_4_X if BR2_sparc_sparchfleon || BR2_sparc_sparchfleonv8 || BR2_sparc_sparcsfleon || BR2_sparc_sparcsfleonv8
-	default BR2_GCC_VERSION_4_2_2_AVR32_2_1_5 if BR2_avr32
-	default BR2_GCC_VERSION_4_4_7_ARC if BR2_arc
+	depends on !(BR2_arc			|| \
+		     BR2_avr32			|| \
+		     BR2_sparc_sparchfleon	|| \
+		     BR2_sparc_sparchfleonv8	|| \
+		     BR2_sparc_sparcsfleon	|| \
+		     BR2_sparc_sparcsfleonv8)
 	default BR2_GCC_VERSION_4_7_X
 	help
 	  Select the version of gcc you wish to use.
 
-	config BR2_GCC_VERSION_4_4_7_ARC
-		depends on BR2_arc
-		bool "gcc 4.4.7-arc"
-
-	config BR2_GCC_VERSION_4_2_2_AVR32_2_1_5
-	       depends on BR2_avr32
-	       bool "gcc 4.2.2-avr32-2.1.5"
-
 	config BR2_GCC_VERSION_4_3_X
-		depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 && !BR2_cortex_a5 && !BR2_cortex_a8 && !BR2_cortex_a9 && !BR2_cortex_a15 && !BR2_x86_atom && !BR2_powerpc_e300c2 && !BR2_powerpc_e300c3 && !BR2_powerpc_e500mc && !BR2_powerpc_464 && !BR2_powerpc_464fp && !BR2_powerpc_476 && !BR2_powerpc_476fp && !BR2_fa526 && !BR2_pj4
+		depends on BR2_ARCH_HAS_ALL_GCC
 		bool "gcc 4.3.x"
 
 	config BR2_GCC_VERSION_4_4_X
-		depends on !BR2_arc && !BR2_avr32 && !BR2_cortex_a5 && !BR2_cortex_a15 && !BR2_x86_atom && !BR2_powerpc_476 && !BR2_powerpc_476fp && !BR2_fa526 && !BR2_pj4
+		depends on BR2_ARCH_HAS_GCC_4_4_PLUS || BR2_ARCH_HAS_ALL_GCC
 		bool "gcc 4.4.x"
 
 	config BR2_GCC_VERSION_4_5_X
-		depends on !BR2_arc && !BR2_avr32 && !BR2_cortex_a15 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 && !BR2_fa526 && !BR2_pj4
+		depends on BR2_ARCH_HAS_GCC_4_5_PLUS || BR2_ARCH_HAS_ALL_GCC
 		select BR2_GCC_NEEDS_MPC
 		bool "gcc 4.5.x"
 
 	config BR2_GCC_VERSION_4_6_X
-		depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 && !BR2_pj4
+		depends on BR2_ARCH_HAS_GCC_4_6_PLUS || BR2_ARCH_HAS_ALL_GCC
 		select BR2_GCC_NEEDS_MPC
 		bool "gcc 4.6.x"
 
 	config BR2_GCC_VERSION_4_7_X
-		depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8 && !BR2_pj4
+		depends on BR2_ARCH_HAS_GCC_4_7_PLUS || BR2_ARCH_HAS_ALL_GCC
 		select BR2_GCC_NEEDS_MPC
 		bool "gcc 4.7.x"
 
 	config BR2_GCC_VERSION_4_8_X
-		depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8
+		depends on BR2_ARCH_HAS_GCC_4_8_PLUS || BR2_ARCH_HAS_ALL_GCC
 		select BR2_GCC_NEEDS_MPC
 		bool "gcc 4.8.x"
 
 	config BR2_GCC_VERSION_SNAP
-		depends on !BR2_arc && !BR2_avr32 && !BR2_sparc_sparchfleon && !BR2_sparc_sparchfleonv8 && !BR2_sparc_sparcsfleon && !BR2_sparc_sparcsfleonv8
+		depends on BR2_ARCH_HAS_GCC_SNAP_ONLY || BR2_ARCH_HAS_ALL_GCC
 		select BR2_GCC_NEEDS_MPC
 		bool "gcc snapshot"
 endchoice
@@ -76,10 +103,14 @@ config BR2_GCC_SNAP_DATE
 
 config BR2_GCC_VERSION
 	string
-	default "4.2.2-avr32-2.1.5" if BR2_GCC_VERSION_4_2_2_AVR32_2_1_5
+	default "4.2.2-avr32-2.1.5" if BR2_avr32
 	default "4.3.6"     if BR2_GCC_VERSION_4_3_X
-	default "4.4.7"     if BR2_GCC_VERSION_4_4_X
-	default "4.4.7-arc" if BR2_GCC_VERSION_4_4_7_ARC
+	default "4.4.7"     if (BR2_GCC_VERSION_4_4_X	|| \
+				BR2_sparc_sparchfleon	|| \
+				BR2_sparc_sparchfleonv8	|| \
+				BR2_sparc_sparcsfleon	|| \
+				BR2_sparc_sparcsfleonv8)
+	default "4.4.7-arc" if BR2_arc
 	default "4.5.4"     if BR2_GCC_VERSION_4_5_X
 	default "4.6.4"     if BR2_GCC_VERSION_4_6_X
 	default "4.7.3"     if BR2_GCC_VERSION_4_7_X
-- 
1.7.0.4

[Buildroot] [PATCH] toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS

[Arnout Vandecappelle]

On 03/05/13 10:37, Mischa Jonker wrote:
> 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.
>
> Signed-off-by: Mischa Jonker<mjonker@synopsys.com>
> ---
>   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

Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>


  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

-- 
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

[Buildroot] [PATCH] toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Fri, 03 May 2013 18:31:56 +0200, Arnout Vandecappelle wrote:

>   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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS

[Thomas De Schampheleire]

Hi,

On Fri, May 3, 2013 at 6:31 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 03/05/13 10:37, Mischa Jonker wrote:
>>
>> 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.
>>
>> Signed-off-by: Mischa Jonker<mjonker@synopsys.com>
>> ---
>>   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
>
> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>
>

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

[Buildroot] [PATCH] toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS

[Thomas De Schampheleire]

Hi Sam, Konrad,

On Fri, May 3, 2013 at 11:48 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Arnout Vandecappelle,
>
> On Fri, 03 May 2013 18:31:56 +0200, Arnout Vandecappelle wrote:
>
>>   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.

I'm reviving this older thread.
Are any of you still interested in SPARC support in buildroot (see above) ?

Thanks,
Thomas

[Buildroot] [PATCH] toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS

[Andreas Larsson]

On 2013-08-06 22:39, Sam Ravnborg wrote:
> On Wed, Jul 31, 2013 at 08:53:15AM +0200, Thomas De Schampheleire wrote:
>> Hi Sam, Konrad,
>>
>> On Fri, May 3, 2013 at 11:48 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear Arnout Vandecappelle,
>>>
>>> On Fri, 03 May 2013 18:31:56 +0200, Arnout Vandecappelle wrote:
>>>
>>>>    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.
>>
>> 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.
>
> 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

[Buildroot] [PATCH] toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS

[Andreas Larsson]

On 2013-08-06 22:39, Sam Ravnborg wrote:
> On Wed, Jul 31, 2013 at 08:53:15AM +0200, Thomas De Schampheleire wrote:
>> Hi Sam, Konrad,
>>
>> On Fri, May 3, 2013 at 11:48 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear Arnout Vandecappelle,
>>>
>>> On Fri, 03 May 2013 18:31:56 +0200, Arnout Vandecappelle wrote:
>>>
>>>>    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.
>>
>> 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.
>
> 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