[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.
Move the warning to an error as we have been promising would happen in this release.
Signed-off-by: Tom Rini trini@konsulko.com --- arch/arm/config.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 1a77779db4de..02f61fcc3cba 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -68,8 +68,8 @@ endif checkgcc6: @if test "$(call cc-name)" = "gcc" -a \ "$(call cc-version)" -lt "0600"; then \ - echo -n '*** Your GCC is older than 6.0 and will not be '; \ - echo 'supported starting in v2018.01.'; \ + echo '*** Your GCC is older than 6.0 and is not supported'; \ + false; \ fi
On Sat, Dec 02, 2017 at 08:12:02PM -0500, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
On 12/02/2017 06:12 PM, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the "2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix this as soon as development starts for 2018.01":-(
Is there a reason for requiring such an extremely new gcc, as opposed to simply something not ancient? For example, no LTS version of Ubuntu packages a compiler that's new enough to build U-Boot now:-(
On Mon, Dec 04, 2017 at 12:02:20PM -0700, Stephen Warren wrote:
On 12/02/2017 06:12 PM, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the "2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix this as soon as development starts for 2018.01":-(
I'm tagging v2018.01-rc1 later today, so I think this is about the time to enforce the warning.
Is there a reason for requiring such an extremely new gcc, as opposed to simply something not ancient? For example, no LTS version of Ubuntu packages a compiler that's new enough to build U-Boot now:-(
There's always the Free Electrons toolchains, as well as Linaro. And yes, we've been having size problems and having to play various games to allow for older gcc versions to still fit things in. GCC-6 is where https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 was resolved and we get a lot of space saved, and a number of platforms simply won't work with older.
Hello Tom,
Am 04.12.2017 um 20:09 schrieb Tom Rini:
On Mon, Dec 04, 2017 at 12:02:20PM -0700, Stephen Warren wrote:
On 12/02/2017 06:12 PM, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the "2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix this as soon as development starts for 2018.01":-(
I'm tagging v2018.01-rc1 later today, so I think this is about the time to enforce the warning.
Is there a reason for requiring such an extremely new gcc, as opposed to simply something not ancient? For example, no LTS version of Ubuntu packages a compiler that's new enough to build U-Boot now:-(
There's always the Free Electrons toolchains, as well as Linaro. And yes, we've been having size problems and having to play various games to
Yes, I have the AT91 based smartweb board, for which the SPL have to fit into 4k sram (is in my weekly tbot builds).
allow for older gcc versions to still fit things in. GCC-6 is where https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 was resolved and we get a lot of space saved, and a number of platforms simply won't work with older.
Just looked at:
http://toolchains.free-electrons.com/
for example the stable toolchains for arm are gcc 5.4.0 based.
Ok, there is the "bleeding-edge" ... gcc 7.2.0 based...
Hmm.. linaro has 7.2.0 in its latest release ... so, currently only linaro toolchain can be used for compiling U-Boot ?
setup the tbot tests with linaro toolchain: https://releases.linaro.org/components/toolchain/binaries/7.2-2017.11/arm-li...
Ok, build for corvus board works, see:
http://xeidos.ddns.net/tests/test_db_auslesen.php#528
but for the smartweb board I get:
LD spl/drivers/built-in.o LD spl/u-boot-spl arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 16 bytes make[1]: *** [scripts/Makefile.spl:343: spl/u-boot-spl] Error 1 make: *** [Makefile:1394: spl/u-boot-spl] Error 2 hs@pollux [ 7:48:49] ttbott>
:-(
Full log: http://xeidos.ddns.net/tbot/id_529/tbot.txt
This build worked last week with gcc 4.9.2, see
http://xeidos.ddns.net/tbot/id_515/tbot.txt
bye, Heiko
On Tue, Dec 5, 2017 at 6:53 AM, Heiko Schocher hs@denx.de wrote:
Hello Tom,
Am 04.12.2017 um 20:09 schrieb Tom Rini:
On Mon, Dec 04, 2017 at 12:02:20PM -0700, Stephen Warren wrote:
On 12/02/2017 06:12 PM, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the "2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix this as soon as development starts for 2018.01":-(
I'm tagging v2018.01-rc1 later today, so I think this is about the time to enforce the warning.
Is there a reason for requiring such an extremely new gcc, as opposed to simply something not ancient? For example, no LTS version of Ubuntu packages a compiler that's new enough to build U-Boot now:-(
There's always the Free Electrons toolchains, as well as Linaro. And yes, we've been having size problems and having to play various games to
Yes, I have the AT91 based smartweb board, for which the SPL have to fit into 4k sram (is in my weekly tbot builds).
allow for older gcc versions to still fit things in. GCC-6 is where https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 was resolved and we get a lot of space saved, and a number of platforms simply won't work with older.
Just looked at:
http://toolchains.free-electrons.com/
for example the stable toolchains for arm are gcc 5.4.0 based.
Ok, there is the "bleeding-edge" ... gcc 7.2.0 based...
Hmm.. linaro has 7.2.0 in its latest release ... so, currently only linaro toolchain can be used for compiling U-Boot ?
I've been using gcc 7.x in Fedora since the beginning of the year to build u-boot
Hello Tom, Stephen,
Am 04.12.2017 um 20:02 schrieb Stephen Warren:
On 12/02/2017 06:12 PM, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the "2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix this as soon as development starts for 2018.01":-(
Yes, all my U-Boot tbot builds tonight failed :-(
I use eldk-5.8 (gcc 4.9.2) or I fetch toolchain with buildman from kernel org:
pollux:u-boot hs [ubi-rework] $ ./tools/buildman/buildman --fetch-arch arm
Downloading toolchain for arch 'arm' Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/ Downloading: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc... Unpacking to: /home/hs/.buildman-toolchains Testing - looking in '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/.' - looking in '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin' - found '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc' - looking in '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/usr/bin' Tool chain test: OK, arch='arm', priority 4 pollux:u-boot hs [ubi-rework] $
Which has gcc 4.9.0 ...
Is there a reason for requiring such an extremely new gcc, as opposed to simply something not ancient? For example, no LTS version of Ubuntu packages a compiler that's new enough to build U-Boot now:-(
bye, Heiko
On Tue, Dec 05, 2017 at 06:02:16AM +0100, Heiko Schocher wrote:
Hello Tom, Stephen,
Am 04.12.2017 um 20:02 schrieb Stephen Warren:
On 12/02/2017 06:12 PM, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the "2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix this as soon as development starts for 2018.01":-(
Yes, all my U-Boot tbot builds tonight failed :-(
I use eldk-5.8 (gcc 4.9.2) or I fetch toolchain with buildman from kernel org:
pollux:u-boot hs [ubi-rework] $ ./tools/buildman/buildman --fetch-arch arm
Downloading toolchain for arch 'arm' Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/ Downloading: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc... Unpacking to: /home/hs/.buildman-toolchains Testing - looking in '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/.' - looking in '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin' - found '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc' - looking in '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/usr/bin' Tool chain test: OK, arch='arm', priority 4 pollux:u-boot hs [ubi-rework] $
Which has gcc 4.9.0 ...
I guess it's time, really, to make buildman fetch from the free electrons toolchains instead of the old kernel.org ones, can you take a pass at that? Thanks!
On 4 Dec 2017, at 20:02, Stephen Warren swarren@wwwdotorg.org wrote:
On 12/02/2017 06:12 PM, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the "2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix this as soon as development starts for 2018.01":-(
Is there a reason for requiring such an extremely new gcc, as opposed to simply something not ancient?
GCC-6 matches the definition of “not ancient”. We’ve just gone to phase 3 on GCC-8 a few weeks back, so GCC-6 will be 2 years old in April.
Usually, toolchains for embedded targets are maintained on a “stable” and “one behind-stable” basis. Which already makes GCC-6 the oldest toolchain that will receive backports. For example, Linaro now has GCC-6 and GCC-7 trees and will retire the GCC-6 tree once GCC-8 becomes stable (i.e. once 8.1.0 comes out in about April).
For example, no LTS version of Ubuntu packages a compiler that's new enough to build U-Boot now:-(
I recommend crosstools-ng for situations like this… in fact, I recommend crosstools-ng for any setup. Building a [target]-elf toolchain really doesn’t take long.
Best regards, Philipp.
On 12/05/2017 03:32 AM, Dr. Philipp Tomsich wrote:
On 4 Dec 2017, at 20:02, Stephen Warren swarren@wwwdotorg.org wrote:
On 12/02/2017 06:12 PM, Tom Rini wrote:
Move the warning to an error as we have been promising would happen in this release.
Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the "2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix this as soon as development starts for 2018.01":-(
Is there a reason for requiring such an extremely new gcc, as opposed to simply something not ancient?
GCC-6 matches the definition of “not ancient”. We’ve just gone to phase 3 on GCC-8 a few weeks back, so GCC-6 will be 2 years old in April.
I disagree here. LTS Ubuntu (as an example of one reasonable distro that one might use) is only released every 2 years, and multiple of them are fully supported in parallel (so older releases are also reasonable to use). A 2-year-old toolchain is just old enough that one single LTS distro release /might/ have picked it up (in this case, this hasn't happened yet). To me, "not ancient" means "not 5 years old or more", where "5" is somewhat arbitary and could easily be 5-10 say, but certainly not a very small number like 2.
FWIW, I managed to get my systems running using Linaro gcc-7.2.1 2017.11. However, the process was annoying since the older internal U-Boot branches we still support don't support anything /newer/ than gcc-5 (even for releases only about 1.5 years old; U-Boot jumped forward on compilers extremely fast with little overlap in support), so I had to make my system use a different toolchain for different builds:-( At least I have the infrastructure in place for this for next time.
participants (5)
-
Dr. Philipp Tomsich -
Heiko Schocher -
Peter Robinson -
Stephen Warren -
Tom Rini