| Message ID | 1388143942-1187-5-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Accepted |
| Headers | show |
Thomas, All, On 2013-12-27 12:32 +0100, Thomas Petazzoni spake thusly: > Add Linaro AArch64 2013.10 and Linaro AArch64 2013.11, and remove > Linaro AArch64 2013.07 and Linaro AArch64 2013.08. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> But see below, unrelated comment... [--SNIP--] > diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk > index 0e12c76..6a44eaf 100644 > --- a/toolchain/toolchain-external/toolchain-external.mk > +++ b/toolchain/toolchain-external/toolchain-external.mk > @@ -339,15 +339,15 @@ TOOLCHAIN_EXTERNAL_SOURCE = lin32-microblaze-unknown-linux-gnu_14.3_early.tar.xz > else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_XILINX_MICROBLAZEBE_V2),y) > TOOLCHAIN_EXTERNAL_SITE = http://sources.buildroot.net/ > TOOLCHAIN_EXTERNAL_SOURCE = microblaze-unknown-linux-gnu.tgz > -else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_07),y) > -TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.07/components/toolchain/binaries/ > -TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.07-1_linux.tar.xz > -else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_08),y) > -TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.08/components/toolchain/binaries/ > -TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.08_linux.tar.xz > else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_09),y) > TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.09/components/toolchain/binaries/ > TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.xz > +else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_10),y) > +TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.10/components/toolchain/binaries/ > +TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.10-1_linux.tar.xz > +else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_11),y) > +TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.11/components/toolchain/binaries/ > +TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.11_linux.tar.xz > else > # Custom toolchain > TOOLCHAIN_EXTERNAL_SITE = $(dir $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_URL))) I find it odd that the menu are listed with reverse order, most recent first, while the Makefiles are listed in order, oldest first. This applies to all toolchains, not only the Linaro ones. Of course, this is not the fault of this patch, as you kept the previous order. So it does not bar you from applying it. Regards, Yann E. MORIN.
Hi Thomas, On Fri, Dec 27, 2013 at 12:32 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Add Linaro AArch64 2013.10 and Linaro AArch64 2013.11, and remove > Linaro AArch64 2013.07 and Linaro AArch64 2013.08. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> A while back we discussed the desirability of having so many subsequent versions of the same toolchain type (in this case Linaro). IIRC (but I did not cross-check with the actual discussion yet) the conclusion was that it'd be good to use the gcc version as milestone, and keep e.g. a 4.4, 4.6, 4.8 gcc based Linaro toolchain, but not keep multiple 4.8-based versions. Until now this has not yet been implemented. We could do this in a one-shot approach, or gradually as new toolchains are added. If we opt for the second option, your current patchset could be revised to align with the new strategy. What do you think about that? Best regards, Thomas
Dear Thomas De Schampheleire, On Sun, 29 Dec 2013 18:40:50 +0100, Thomas De Schampheleire wrote: > On Fri, Dec 27, 2013 at 12:32 PM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: > > Add Linaro AArch64 2013.10 and Linaro AArch64 2013.11, and remove > > Linaro AArch64 2013.07 and Linaro AArch64 2013.08. > > > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > > A while back we discussed the desirability of having so many > subsequent versions of the same toolchain type (in this case Linaro). > IIRC (but I did not cross-check with the actual discussion yet) the > conclusion was that it'd be good to use the gcc version as milestone, > and keep e.g. a 4.4, 4.6, 4.8 gcc based Linaro toolchain, but not keep > multiple 4.8-based versions. > > Until now this has not yet been implemented. We could do this in a > one-shot approach, or gradually as new toolchains are added. If we opt > for the second option, your current patchset could be revised to align > with the new strategy. > > What do you think about that? I continue to think that it doesn't work, as I already expressed originally. Using the gcc version as a way of keeping different generations of toolchain is, in my opinion, broken: in the present update of the ARM Linaro toolchain, we continue to have only gcc 4.8 based toolchains, but the newer ones are based on eglibc 2.18, while the previous ones are based on eglibc 2.17. This is a fairly significant difference, but if we use only the gcc version as the way of distinguishing generations of toolchain, then we would get rid of gcc 4.8/eglibc 2.17 toolchains today. Why would we keep a very old gcc 4.7.x toolchain, but immediately get rid of a more recent gcc 4.8 toolchain that is based on eglibc 2.17 ? As we never managed to come up with a reasonable model to handle this, I believe we should in the mean time continue to update the toolchains as we used to do in the past. Thanks! Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, > Why would we keep a very old gcc 4.7.x toolchain, but immediately get > rid of a more recent gcc 4.8 toolchain that is based on eglibc 2.17 ? > As we never managed to come up with a reasonable model to handle this, > I believe we should in the mean time continue to update the toolchains > as we used to do in the past. Agreed.
Hi, On Sun, Dec 29, 2013 at 10:51 PM, Peter Korsgaard <jacmet@uclibc.org> wrote: >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > Hi, > > > Why would we keep a very old gcc 4.7.x toolchain, but immediately get > > rid of a more recent gcc 4.8 toolchain that is based on eglibc 2.17 ? > > > As we never managed to come up with a reasonable model to handle this, > > I believe we should in the mean time continue to update the toolchains > > as we used to do in the past. > > Agreed. While I agree that the existing patchset could continue in the meanwhile, I think it is worth revisiting the core discussion. For reference, here is the previous discussion: http://lists.busybox.net/pipermail/buildroot/2013-October/080119.html Back then (October) there was not much debate about the idea of only providing sufficiently-different versions of the Linaro toolchains. The biggest problem was how to identify the toolchains so that 'minor' updates can keep the same config symbol (and thus be transparent to users). This boils down to the question: which parts of the toolchain may change to continue considering it as 'the same' toolchain. I think everyone will agree that a new gcc version or a new C library version means a different toolchain. However, what about the other parts? If Linaro updates binutils, do we consider it the same toolchain or not? Based on this we could devise some logical names of the config symbols. Note that this does not mean we can't change our minds later. Suppose we start with the gcc/libc combination as key, and we'd have symbols LINARO_GCC_4_8_GLIBC_2_17 LINARO_GCC_4_8_GLIBC_2_18 LINARO_GCC_5_0_GLIBC_2_18 and suddenly Linaro releases a toolchain with the same gcc and glibc version, but some other change that we consider as significant. Then at that point we can simply introduce a new symbol and keep both, for example: LINARO_GCC_4_8_GLIBC_2_17 LINARO_GCC_4_8_GLIBC_2_18 LINARO_GCC_5_0_GLIBC_2_18 LINARO_GCC_5_0_GLIBC_2_18_OTHER_FEATURE Does this make sense? Did I overlook something? Thanks, Thomas
Dear Thomas De Schampheleire, Happy new year! On Thu, 2 Jan 2014 14:17:31 +0100, Thomas De Schampheleire wrote: > While I agree that the existing patchset could continue in the > meanwhile, I think it is worth revisiting the core discussion. For > reference, here is the previous discussion: > http://lists.busybox.net/pipermail/buildroot/2013-October/080119.html > > Back then (October) there was not much debate about the idea of only > providing sufficiently-different versions of the Linaro toolchains. > The biggest problem was how to identify the toolchains so that 'minor' > updates can keep the same config symbol (and thus be transparent to > users). This boils down to the question: which parts of the toolchain > may change to continue considering it as 'the same' toolchain. > I think everyone will agree that a new gcc version or a new C library > version means a different toolchain. > However, what about the other parts? If Linaro updates binutils, do we > consider it the same toolchain or not? > > Based on this we could devise some logical names of the config symbols. > Note that this does not mean we can't change our minds later. Suppose > we start with the gcc/libc combination as key, and we'd have symbols > LINARO_GCC_4_8_GLIBC_2_17 > LINARO_GCC_4_8_GLIBC_2_18 > LINARO_GCC_5_0_GLIBC_2_18 > > and suddenly Linaro releases a toolchain with the same gcc and glibc > version, but some other change that we consider as significant. Then > at that point we can simply introduce a new symbol and keep both, for > example: > LINARO_GCC_4_8_GLIBC_2_17 > LINARO_GCC_4_8_GLIBC_2_18 > LINARO_GCC_5_0_GLIBC_2_18 > LINARO_GCC_5_0_GLIBC_2_18_OTHER_FEATURE > > Does this make sense? Did I overlook something? My personal view on this is that I still don't really understand what is the problem with the current naming scheme. If an user upgrades from one Buildroot version to another then the version of all components *are* changing, without changes to the corresponding Config.in symbol. You update Buildroot, then suddenly you get Qt 5.2 instead of Qt 5.1, without being notified. At the next Buildroot upgrade, you may still be using Qt 5.2, or Qt 5.2.1, or Qt 5.3, or 5.4. You have to verify it. With Linaro toolchains, if you use Linaro 2013.02 in your Buildroot configuration, then update to a new Buildroot version that still has Linaro 2013.02, then you will continue to use this toolchain. However, if Buildroot has updated a number of Linaro toolchains, and 2013.02 is no longer available, you will automatically default to the latest Linaro toolchain that exists for your architecture, maybe 2013.06 or 2013.07. What's the difference with Qt? I don't see any, to be honest. Best regards, Thomas
Hi Thomas, On Thu, Jan 2, 2014 at 2:29 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Thomas De Schampheleire, > > Happy new year! I should have started with that :) Thanks, same to you and to all buildroot users/developers! > > On Thu, 2 Jan 2014 14:17:31 +0100, Thomas De Schampheleire wrote: > >> While I agree that the existing patchset could continue in the >> meanwhile, I think it is worth revisiting the core discussion. For >> reference, here is the previous discussion: >> http://lists.busybox.net/pipermail/buildroot/2013-October/080119.html >> >> Back then (October) there was not much debate about the idea of only >> providing sufficiently-different versions of the Linaro toolchains. >> The biggest problem was how to identify the toolchains so that 'minor' >> updates can keep the same config symbol (and thus be transparent to >> users). This boils down to the question: which parts of the toolchain >> may change to continue considering it as 'the same' toolchain. >> I think everyone will agree that a new gcc version or a new C library >> version means a different toolchain. >> However, what about the other parts? If Linaro updates binutils, do we >> consider it the same toolchain or not? >> >> Based on this we could devise some logical names of the config symbols. >> Note that this does not mean we can't change our minds later. Suppose >> we start with the gcc/libc combination as key, and we'd have symbols >> LINARO_GCC_4_8_GLIBC_2_17 >> LINARO_GCC_4_8_GLIBC_2_18 >> LINARO_GCC_5_0_GLIBC_2_18 >> >> and suddenly Linaro releases a toolchain with the same gcc and glibc >> version, but some other change that we consider as significant. Then >> at that point we can simply introduce a new symbol and keep both, for >> example: >> LINARO_GCC_4_8_GLIBC_2_17 >> LINARO_GCC_4_8_GLIBC_2_18 >> LINARO_GCC_5_0_GLIBC_2_18 >> LINARO_GCC_5_0_GLIBC_2_18_OTHER_FEATURE >> >> Does this make sense? Did I overlook something? > > My personal view on this is that I still don't really understand what > is the problem with the current naming scheme. If an user upgrades from > one Buildroot version to another then the version of all components > *are* changing, without changes to the corresponding Config.in symbol. > You update Buildroot, then suddenly you get Qt 5.2 instead of Qt 5.1, > without being notified. At the next Buildroot upgrade, you may still be > using Qt 5.2, or Qt 5.2.1, or Qt 5.3, or 5.4. You have to verify it. > > With Linaro toolchains, if you use Linaro 2013.02 in your Buildroot > configuration, then update to a new Buildroot version that still has > Linaro 2013.02, then you will continue to use this toolchain. However, > if Buildroot has updated a number of Linaro toolchains, and 2013.02 is > no longer available, you will automatically default to the latest > Linaro toolchain that exists for your architecture, maybe 2013.06 or > 2013.07. > > What's the difference with Qt? I don't see any, to be honest. One big difference is that for qt5 you cannot select the version, you just say "I want qt5". For the external toolchains, you specify a particular version, out of a set of provided versions. The problem arises when we introduce support for a newer version. For qt5 (and most packages) we simply replace the old version with the new one. No notification. No migration. For toolchains (and some other packages) we add the new version, and typically remove one or more old versions. The question is now: which toolchains to remove? - The oldest one? This is the approach taken currently for Linaro toolchains. - The latest, most similar one? For Sourcery toolchains, there are versions and patch levels. The introduction of a toolchain version 2013.11 patchlevel 50 will overwrite the previous toolchain 2013.11 patchlevel 40 (just an example). We don't keep two patchlevels of the same toolchain version. For Linaro, there are no real patchlevels (as far as I understood, I'm no expert there) but they call everything a new 'version'. Thus, the Linaro toolchains are released much more frequently than for Sourcery toolchains. This blend of the version and patchlevel is the cause of this discussion, I believe. Two subsequent Linaro releases could be considered as two different versions, or as one version but different patchlevel (in Sourcery terminology). The classification used would determine what to do with the buildroot config symbols (which ones to add and which to remove). If it's a new 'version' we'd remove the oldest existing version and add the new one. If it's a new 'patchlevel', we'd remove the most recent toolchain of the same 'version' (same combination of most important components) but different 'patchlevel'. This approach more or less requires different names of the config symbols, unless we'd accept that config symbol LINARO_2013.11 could actually install Linaro 2013.12 (example only). Best regards, Thomas
diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in index e32a16e..4c3c8a4 100644 --- a/toolchain/toolchain-external/Config.in +++ b/toolchain/toolchain-external/Config.in @@ -747,8 +747,8 @@ config BR2_TOOLCHAIN_EXTERNAL_XILINX_MICROBLAZEBE_V2 Toolchain for the Microblaze architecture, from http://wiki.xilinx.com/mb-gnu-tools -config BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_09 - bool "Linaro AArch64 13.09" +config BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_11 + bool "Linaro AArch64 13.11" depends on BR2_aarch64 depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" depends on !BR2_PREFER_STATIC_LIB @@ -760,8 +760,8 @@ config BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_09 Toolchain for the AArch64 architecture, from http://www.linaro.org/engineering/armv8/ -config BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_08 - bool "Linaro AArch64 13.08" +config BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_10 + bool "Linaro AArch64 13.10" depends on BR2_aarch64 depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" depends on !BR2_PREFER_STATIC_LIB @@ -773,8 +773,8 @@ config BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_08 Toolchain for the AArch64 architecture, from http://www.linaro.org/engineering/armv8/ -config BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_07 - bool "Linaro AArch64 13.07" +config BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_09 + bool "Linaro AArch64 13.09" depends on BR2_aarch64 depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" depends on !BR2_PREFER_STATIC_LIB @@ -844,9 +844,9 @@ config BR2_TOOLCHAIN_EXTERNAL_PREFIX default "arm-none-linux-gnueabi" if BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201311 default "arm-arago-linux-gnueabi" if BR2_TOOLCHAIN_EXTERNAL_ARAGO_ARMV7A_201109 default "arm-arago-linux-gnueabi" if BR2_TOOLCHAIN_EXTERNAL_ARAGO_ARMV5TE_201109 + default "aarch64-linux-gnu" if BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_11 + default "aarch64-linux-gnu" if BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_10 default "aarch64-linux-gnu" if BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_09 - default "aarch64-linux-gnu" if BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_08 - default "aarch64-linux-gnu" if BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_07 default "microblazeel-unknown-linux-gnu" if BR2_TOOLCHAIN_EXTERNAL_XILINX_MICROBLAZEEL_14_3 default "microblazeel-unknown-linux-gnu" if BR2_TOOLCHAIN_EXTERNAL_XILINX_MICROBLAZEEL_V2 default "microblaze-unknown-linux-gnu" if BR2_TOOLCHAIN_EXTERNAL_XILINX_MICROBLAZEBE_14_3 diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk index 0e12c76..6a44eaf 100644 --- a/toolchain/toolchain-external/toolchain-external.mk +++ b/toolchain/toolchain-external/toolchain-external.mk @@ -339,15 +339,15 @@ TOOLCHAIN_EXTERNAL_SOURCE = lin32-microblaze-unknown-linux-gnu_14.3_early.tar.xz else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_XILINX_MICROBLAZEBE_V2),y) TOOLCHAIN_EXTERNAL_SITE = http://sources.buildroot.net/ TOOLCHAIN_EXTERNAL_SOURCE = microblaze-unknown-linux-gnu.tgz -else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_07),y) -TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.07/components/toolchain/binaries/ -TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.07-1_linux.tar.xz -else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_08),y) -TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.08/components/toolchain/binaries/ -TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.08_linux.tar.xz else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_09),y) TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.09/components/toolchain/binaries/ TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.xz +else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_10),y) +TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.10/components/toolchain/binaries/ +TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.10-1_linux.tar.xz +else ifeq ($(BR2_TOOLCHAIN_EXTERNAL_LINARO_AARCH64_13_11),y) +TOOLCHAIN_EXTERNAL_SITE = http://releases.linaro.org/13.11/components/toolchain/binaries/ +TOOLCHAIN_EXTERNAL_SOURCE = gcc-linaro-aarch64-linux-gnu-4.8-2013.11_linux.tar.xz else # Custom toolchain TOOLCHAIN_EXTERNAL_SITE = $(dir $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_URL)))
Add Linaro AArch64 2013.10 and Linaro AArch64 2013.11, and remove Linaro AArch64 2013.07 and Linaro AArch64 2013.08. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- toolchain/toolchain-external/Config.in | 16 ++++++++-------- toolchain/toolchain-external/toolchain-external.mk | 12 ++++++------ 2 files changed, 14 insertions(+), 14 deletions(-)