[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=bb58fafbd9fba9fe0da9c476bca734b5fa13f5b1
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
 toolchain/toolchain-external/Config.in             |   20 ++++++++++----------
 toolchain/toolchain-external/toolchain-external.mk |    6 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in
index 67f4fc7..ecfe17c 100644
--- a/toolchain/toolchain-external/Config.in
+++ b/toolchain/toolchain-external/Config.in
@@ -3,8 +3,8 @@ if BR2_TOOLCHAIN_EXTERNAL
 choice
 	prompt "Toolchain"
 
-config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_08
-	bool "Linaro 2013.08"
+config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_09
+	bool "Linaro 2013.09"
 	depends on BR2_arm
 	depends on BR2_GCC_TARGET_ARCH = "armv7-a"
 	depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
@@ -15,7 +15,7 @@ config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_08
 	select BR2_HOSTARCH_NEEDS_IA32_LIBS
 	help
 	  Linaro toolchain for the ARM architecture. It uses Linaro
-	  GCC 2013.08 (based on gcc 4.8), Linaro GDB 2013.05 (based on
+	  GCC 2013.09 (based on gcc 4.8), Linaro GDB 2013.05 (based on
 	  GDB 7.6), eglibc 2.17, Binutils 2013.06 (based on 2.23). It
 	  generates code that runs on all Cortex-A profile devices,
 	  but tuned for the Cortex-A9. The code generated is Thumb 2,
@@ -24,8 +24,8 @@ config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_08
 
 	  To use this toolchain, you must disable soft float usage.
 
-config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_07
-	bool "Linaro 2013.07"
+config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_08
+	bool "Linaro 2013.08"
 	depends on BR2_arm
 	depends on BR2_GCC_TARGET_ARCH = "armv7-a"
 	depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
@@ -36,7 +36,7 @@ config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_07
 	select BR2_HOSTARCH_NEEDS_IA32_LIBS
 	help
 	  Linaro toolchain for the ARM architecture. It uses Linaro
-	  GCC 2013.07 (based on gcc 4.8), Linaro GDB 2013.05 (based on
+	  GCC 2013.08 (based on gcc 4.8), Linaro GDB 2013.05 (based on
 	  GDB 7.6), eglibc 2.17, Binutils 2013.06 (based on 2.23). It
 	  generates code that runs on all Cortex-A profile devices,
 	  but tuned for the Cortex-A9. The code generated is Thumb 2,
@@ -45,8 +45,8 @@ config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_07
 
 	  To use this toolchain, you must disable soft float usage.
 
-config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_06
-	bool "Linaro 2013.06"
+config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_07
+	bool "Linaro 2013.07"
 	depends on BR2_arm
 	depends on BR2_GCC_TARGET_ARCH = "armv7-a"
 	depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
@@ -57,7 +57,7 @@ config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_06
 	select BR2_HOSTARCH_NEEDS_IA32_LIBS
 	help
 	  Linaro toolchain for the ARM architecture. It uses Linaro
-	  GCC 2013.06 (based on gcc 4.8), Linaro GDB 2013.05 (based on
+	  GCC 2013.07 (based on gcc 4.8), Linaro GDB 2013.05 (based on
 	  GDB 7.6), eglibc 2.17, Binutils 2013.06 (based on 2.23). It
 	  generates code that runs on all Cortex-A profile devices,
 	  but tuned for the Cortex-A9. The code generated is Thumb 2,
@@ -816,9 +816,9 @@ config BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX
 
 config BR2_TOOLCHAIN_EXTERNAL_PREFIX
 	string
+	default "arm-linux-gnueabihf"	 if BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_09
 	default "arm-linux-gnueabihf"	 if BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_08
 	default "arm-linux-gnueabihf"	 if BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_07
-	default "arm-linux-gnueabihf"	 if BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_06
 	default "arm-none-linux-gnueabi" if BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201109
 	default "arm-none-linux-gnueabi" if BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201203
 	default "arm-none-linux-gnueabi" if BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201305
diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk
index b2266b6..e38ee48 100644
--- a/toolchain/toolchain-external/toolchain-external.mk
+++ b/toolchain/toolchain-external/toolchain-external.mk
@@ -239,15 +239,15 @@ define TOOLCHAIN_EXTERNAL_FIXUP_CMDS
 	mv $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/arago-2011.09/armv5te/* $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/
 	rm -rf $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/arago-2011.09/
 endef
-else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_06),y)
-TOOLCHAIN_EXTERNAL_SITE = https://releases.linaro.org/13.06/components/toolchain/binaries/
-TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-arm-linux-gnueabihf-4.8-2013.06_linux.tar.xz
 else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_07),y)
 TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.07/components/toolchain/binaries/
 TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux.tar.xz
 else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_08),y)
 TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.08/components/toolchain/binaries/
 TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux.tar.xz
+else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_09),y)
+TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.09/components/toolchain/binaries/
+TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.xz
 else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_MIPS201203),y)
 TOOLCHAIN_EXTERNAL_SITE = http://sourcery.mentor.com/public/gnu_toolchain/mips-linux-gnu/
 TOOLCHAIN_EXTERNAL_SOURCE = mips-2012.03-63-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Arnout Vandecappelle]

On 10/09/13 16:06, Peter Korsgaard wrote:
> -config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_06
> -	bool "Linaro 2013.06"
> +config BR2_TOOLCHAIN_EXTERNAL_LINARO_2013_07
> +	bool "Linaro 2013.07"

  I believe I asked this before: do we really want to remove external 
toolchains without going through a deprecation cycle? Why do we offer in 
a released buildroot three different Linaro toolchain versions that are 
all gcc 4.8 and that you cannot use anymore three months later?

  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] [git commit] toolchain-external: update Linaro ARM toolchain

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Thu, 10 Oct 2013 08:53:49 +0200, Arnout Vandecappelle wrote:

>   I believe I asked this before: do we really want to remove external 
> toolchains without going through a deprecation cycle? Why do we offer in 
> a released buildroot three different Linaro toolchain versions that are 
> all gcc 4.8 and that you cannot use anymore three months later?

Linaro toolchains are released every month, so they are moving quickly.
What are you proposing to do to handle this?

Have just a BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM option, which maps
automatically to the latest version of the toolchain, like we do for
packages?

Or do you suggest to preserve toolchains? For how long?

Until now, the arbitrarily chosen policy was to keep only three
versions of a given toolchain. For Sourcery CodeBench toolchains, I
believe it works quite well because the frequency of releases is not
too high. However, it's true that for Linaro toolchains, it may not be
appropriate, but I'm not sure what to do exactly.

Thanks for your suggestions,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Luca Ceresoli]

Thomas, Arnout,

Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Thu, 10 Oct 2013 08:53:49 +0200, Arnout Vandecappelle wrote:
>
>>    I believe I asked this before: do we really want to remove external
>> toolchains without going through a deprecation cycle? Why do we offer in
>> a released buildroot three different Linaro toolchain versions that are
>> all gcc 4.8 and that you cannot use anymore three months later?
>
> Linaro toolchains are released every month, so they are moving quickly.
> What are you proposing to do to handle this?
>
> Have just a BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM option, which maps
> automatically to the latest version of the toolchain, like we do for
> packages?
>
> Or do you suggest to preserve toolchains? For how long?
>
> Until now, the arbitrarily chosen policy was to keep only three
> versions of a given toolchain. For Sourcery CodeBench toolchains, I
> believe it works quite well because the frequency of releases is not
> too high. However, it's true that for Linaro toolchains, it may not be
> appropriate, but I'm not sure what to do exactly.

I also would like toolchains to be maintained in BR a little longer, at 
least one year.

Of course maintaining 12 Linaro toolchains would be quite annoying and 
probably useless.

So we may want to add only those Linaro toolchains that have relevant 
changes, say they upgrade gcc or provide some shiny new feature. But 
this may be risky: a newly introduced feature is more likely to be 
buggy. So... how about the 2nd or 3rd release after a relevant change? 
Uhm, quite fuzzy indeed.

Or, more simply, add only one Linaro toolchain per each Buildroot release.

-- 
Luca

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Thomas De Schampheleire]

Hi,

On Fri, Oct 11, 2013 at 11:01 AM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
> Thomas, Arnout,
>
>
> Thomas Petazzoni wrote:
>>
>> Dear Arnout Vandecappelle,
>>
>> On Thu, 10 Oct 2013 08:53:49 +0200, Arnout Vandecappelle wrote:
>>
>>>    I believe I asked this before: do we really want to remove external
>>> toolchains without going through a deprecation cycle? Why do we offer in
>>> a released buildroot three different Linaro toolchain versions that are
>>> all gcc 4.8 and that you cannot use anymore three months later?
>>
>>
>> Linaro toolchains are released every month, so they are moving quickly.
>> What are you proposing to do to handle this?
>>
>> Have just a BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM option, which maps
>> automatically to the latest version of the toolchain, like we do for
>> packages?
>>
>> Or do you suggest to preserve toolchains? For how long?
>>
>> Until now, the arbitrarily chosen policy was to keep only three
>> versions of a given toolchain. For Sourcery CodeBench toolchains, I
>> believe it works quite well because the frequency of releases is not
>> too high. However, it's true that for Linaro toolchains, it may not be
>> appropriate, but I'm not sure what to do exactly.
>
>
> I also would like toolchains to be maintained in BR a little longer, at
> least one year.
>
> Of course maintaining 12 Linaro toolchains would be quite annoying and
> probably useless.
>
> So we may want to add only those Linaro toolchains that have relevant
> changes, say they upgrade gcc or provide some shiny new feature. But this
> may be risky: a newly introduced feature is more likely to be buggy. So...
> how about the 2nd or 3rd release after a relevant change? Uhm, quite fuzzy
> indeed.

The principle of keep three toolchains that differ sufficiently seems
ok to me. I don't think we should care about 'buggy' releases: Linaro
is responsible of delivering quality toolchains. If it happens that a
newly released toolchain is no good for some reason, we can still step
that one back, or take the newer one if it was released in the mean
time.

So, this proposal would for example have (fictional)
Linaro 2012.11 (based on gcc 4.4)
Linaro 2013.02 (gcc 4.4 but new glibc)
Linaro 2013.08 (gcc 4.8)

Best regards,
Thomas

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Fri, 11 Oct 2013 11:16:33 +0200, Thomas De Schampheleire wrote:

> The principle of keep three toolchains that differ sufficiently seems
> ok to me. I don't think we should care about 'buggy' releases: Linaro
> is responsible of delivering quality toolchains. If it happens that a
> newly released toolchain is no good for some reason, we can still step
> that one back, or take the newer one if it was released in the mean
> time.
> 
> So, this proposal would for example have (fictional)
> Linaro 2012.11 (based on gcc 4.4)
> Linaro 2013.02 (gcc 4.4 but new glibc)
> Linaro 2013.08 (gcc 4.8)

Ok. So a bit like the Sourcery CodeBench toolchains are updated to
their latest patch level, but we keep several "major version" with
their latest patch level.

But in the case of Sourcery CodeBench toolchain, we do those patch
level version bumps without changing the Config.in option name, so
the bump is transparent to users.

For the Linaro toolchains, the Config.in option name contain the
precise version. So, what happens when we bump Linaro 2013.08 to Linaro
2012.09 (which also uses gcc 4.8, and therefore should replace Linaro
2012.08) ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Dear Thomas De Schampheleire,
 Thomas> On Fri, 11 Oct 2013 11:16:33 +0200, Thomas De Schampheleire wrote:

 >> The principle of keep three toolchains that differ sufficiently seems
 >> ok to me. I don't think we should care about 'buggy' releases: Linaro
 >> is responsible of delivering quality toolchains. If it happens that a
 >> newly released toolchain is no good for some reason, we can still step
 >> that one back, or take the newer one if it was released in the mean
 >> time.
 >> 
 >> So, this proposal would for example have (fictional)
 >> Linaro 2012.11 (based on gcc 4.4)
 >> Linaro 2013.02 (gcc 4.4 but new glibc)
 >> Linaro 2013.08 (gcc 4.8)

 Thomas> Ok. So a bit like the Sourcery CodeBench toolchains are updated to
 Thomas> their latest patch level, but we keep several "major version" with
 Thomas> their latest patch level.

 Thomas> But in the case of Sourcery CodeBench toolchain, we do those patch
 Thomas> level version bumps without changing the Config.in option name, so
 Thomas> the bump is transparent to users.

 Thomas> For the Linaro toolchains, the Config.in option name contain the
 Thomas> precise version. So, what happens when we bump Linaro 2013.08 to Linaro
 Thomas> 2012.09 (which also uses gcc 4.8, and therefore should replace Linaro
 Thomas> 2012.08) ?

If we want to key off gcc version then we should presumably name the
Config sysmbol similar - E.G.:

config BR2_TOOLCHAIN_EXTERNAL_LINARY_GCC_4_8
       bool "Linaro GCC 4.8 (2013.08)"

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Fri, 11 Oct 2013 12:19:09 +0200, Peter Korsgaard wrote:

>  >> So, this proposal would for example have (fictional)
>  >> Linaro 2012.11 (based on gcc 4.4)
>  >> Linaro 2013.02 (gcc 4.4 but new glibc)
>  >> Linaro 2013.08 (gcc 4.8)
> 
>  Thomas> Ok. So a bit like the Sourcery CodeBench toolchains are updated to
>  Thomas> their latest patch level, but we keep several "major version" with
>  Thomas> their latest patch level.
> 
>  Thomas> But in the case of Sourcery CodeBench toolchain, we do those patch
>  Thomas> level version bumps without changing the Config.in option name, so
>  Thomas> the bump is transparent to users.
> 
>  Thomas> For the Linaro toolchains, the Config.in option name contain the
>  Thomas> precise version. So, what happens when we bump Linaro 2013.08 to Linaro
>  Thomas> 2012.09 (which also uses gcc 4.8, and therefore should replace Linaro
>  Thomas> 2012.08) ?
> 
> If we want to key off gcc version then we should presumably name the
> Config sysmbol similar - E.G.:
> 
> config BR2_TOOLCHAIN_EXTERNAL_LINARY_GCC_4_8
>        bool "Linaro GCC 4.8 (2013.08)"

Problem is that in the example above, Thomas was keying on the gcc
version, or the glibc version. But maybe at some point it's not the gcc
version or glibc version that changed, but the fact that they switched
for EABI to EABIhf.

config BR2_TOOLCHAIN_EXTERNAL_LINARO_VARIANT_1
config BR2_TOOLCHAIN_EXTERNAL_LINARO_VARIANT_2
config BR2_TOOLCHAIN_EXTERNAL_LINARO_VARIANT_3

 ? :-)

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Thomas De Schampheleire]

On Fri, Oct 11, 2013 at 12:23 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Peter Korsgaard,
>
> On Fri, 11 Oct 2013 12:19:09 +0200, Peter Korsgaard wrote:
>
>>  >> So, this proposal would for example have (fictional)
>>  >> Linaro 2012.11 (based on gcc 4.4)
>>  >> Linaro 2013.02 (gcc 4.4 but new glibc)
>>  >> Linaro 2013.08 (gcc 4.8)
>>
>>  Thomas> Ok. So a bit like the Sourcery CodeBench toolchains are updated to
>>  Thomas> their latest patch level, but we keep several "major version" with
>>  Thomas> their latest patch level.
>>
>>  Thomas> But in the case of Sourcery CodeBench toolchain, we do those patch
>>  Thomas> level version bumps without changing the Config.in option name, so
>>  Thomas> the bump is transparent to users.
>>
>>  Thomas> For the Linaro toolchains, the Config.in option name contain the
>>  Thomas> precise version. So, what happens when we bump Linaro 2013.08 to Linaro
>>  Thomas> 2012.09 (which also uses gcc 4.8, and therefore should replace Linaro
>>  Thomas> 2012.08) ?
>>
>> If we want to key off gcc version then we should presumably name the
>> Config sysmbol similar - E.G.:
>>
>> config BR2_TOOLCHAIN_EXTERNAL_LINARY_GCC_4_8
>>        bool "Linaro GCC 4.8 (2013.08)"
>
> Problem is that in the example above, Thomas was keying on the gcc
> version, or the glibc version. But maybe at some point it's not the gcc
> version or glibc version that changed, but the fact that they switched
> for EABI to EABIhf.
>
> config BR2_TOOLCHAIN_EXTERNAL_LINARO_VARIANT_1
> config BR2_TOOLCHAIN_EXTERNAL_LINARO_VARIANT_2
> config BR2_TOOLCHAIN_EXTERNAL_LINARO_VARIANT_3
>

Looking at the linaro download page and the names of the tarballs,
they do co-name their toolchains with the gcc version, at least since
2013.

gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.xz
gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux.tar.xz

So, naming the config options like that may not be such a wild idea after all.

Of course, we still have to decide whether we want gcc 4.8, 4.7, and
4.6, or rather larger jumps like
gcc 4.8, 4.4, 4.0 or something like that.

Best regards,
Thomas

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

Hi,

 Thomas> Looking at the linaro download page and the names of the tarballs,
 Thomas> they do co-name their toolchains with the gcc version, at least since
 Thomas> 2013.

 Thomas> gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.xz
 Thomas> gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux.tar.xz

 Thomas> So, naming the config options like that may not be such a wild
 Thomas> idea after all.

Indeed.

 Thomas> Of course, we still have to decide whether we want gcc 4.8, 4.7, and
 Thomas> 4.6, or rather larger jumps like
 Thomas> gcc 4.8, 4.4, 4.0 or something like that.

As we support each individual 4.x version between 4.3 and 4.8 for the
internal toolchain (+/- odd architectures) and Linaro is pretty leading
edge, I would say 4.6 -> 4.8.

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Fri, 11 Oct 2013 13:50:08 +0200, Peter Korsgaard wrote:

>  Thomas> Of course, we still have to decide whether we want gcc 4.8, 4.7, and
>  Thomas> 4.6, or rather larger jumps like
>  Thomas> gcc 4.8, 4.4, 4.0 or something like that.
> 
> As we support each individual 4.x version between 4.3 and 4.8 for the
> internal toolchain (+/- odd architectures) and Linaro is pretty leading
> edge, I would say 4.6 -> 4.8.

This still doesn't solve the case where Linaro 2013.11 would jump from
the next eglibc version, but keeping the same gcc version, for example.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Thomas De Schampheleire]

On Fri, Oct 11, 2013 at 2:11 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Peter Korsgaard,
>
> On Fri, 11 Oct 2013 13:50:08 +0200, Peter Korsgaard wrote:
>
>>  Thomas> Of course, we still have to decide whether we want gcc 4.8, 4.7, and
>>  Thomas> 4.6, or rather larger jumps like
>>  Thomas> gcc 4.8, 4.4, 4.0 or something like that.
>>
>> As we support each individual 4.x version between 4.3 and 4.8 for the
>> internal toolchain (+/- odd architectures) and Linaro is pretty leading
>> edge, I would say 4.6 -> 4.8.
>
> This still doesn't solve the case where Linaro 2013.11 would jump from
> the next eglibc version, but keeping the same gcc version, for example.

It wouldn't solve that case, but maybe it doesn't matter to us. If the
Linaro project co-names their toolchains based on date + gcc, then we
can limit us to that. We then accept whatever eglibc version they
select for that release.

If a user wants to stick to a given eglibc and gcc version, and Linaro
updates eglibc without updating gcc, then that user will have to do
something special. I think it's not realistic for us to handle this in
a clearer way than Linaro does, except by providing a 'custom version'
option.

Best regards,
Thomas

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Fri, 11 Oct 2013 14:15:57 +0200, Thomas De Schampheleire wrote:

> It wouldn't solve that case, but maybe it doesn't matter to us. If the
> Linaro project co-names their toolchains based on date + gcc, then we
> can limit us to that. We then accept whatever eglibc version they
> select for that release.
> 
> If a user wants to stick to a given eglibc and gcc version, and Linaro
> updates eglibc without updating gcc, then that user will have to do
> something special. I think it's not realistic for us to handle this in
> a clearer way than Linaro does, except by providing a 'custom version'
> option.

Ok. From an user perspective, I'm not quite convinced that it makes more
sense to index according to the gcc release than the binutils, gdb, or
eglibc version, or the EABI, or something else, but ok, fair enough.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [git commit] toolchain-external: update Linaro ARM toolchain

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> If a user wants to stick to a given eglibc and gcc version, and Linaro
 >> updates eglibc without updating gcc, then that user will have to do
 >> something special. I think it's not realistic for us to handle this in
 >> a clearer way than Linaro does, except by providing a 'custom version'
 >> option.

 Thomas> Ok. From an user perspective, I'm not quite convinced that it
 Thomas> makes more sense to index according to the gcc release than the
 Thomas> binutils, gdb, or eglibc version, or the EABI, or something
 Thomas> else, but ok, fair enough.

Well, I would argue that the gcc version in general is more important /
has higher impact than the binutils or gdb versions. hard/softfloat
means seperate toolchains (or multilib), so that leaves the eglibc
version.

I agree that ignoring the eglibc version is probably good enough.

-- 
Bye, Peter Korsgaard