arm: Make gcc 6.0 or later a hard requirement now.
PATCH 1/1 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.
--- arch/arm/config.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/config.mk +2 -2
@@ -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
Signature · 1 line
2.7.4
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
Quoted 4 lines · Tom Rini
Move the warning to an error as we have been promising would happen in this release.
Signed-off-by Tom Rini <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171204/c24efa71/attachment.sig>
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
In reply to Tom RiniQuoted 2 lines · Tom Rini
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:-(
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
Quoted 8 lines · Stephen Warren
Quoted 2 lines · Tom Rini
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.
Quoted 3 lines
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.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171204/26c5efbc/attachment.sig>
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
Hello Tom,
Am 04.12.2017 um 20:09 schrieb Tom Rini:
Quoted 13 lines · Stephen Warren
Quoted 8 lines · Tom Rini
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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).
Quoted 4 lines
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-linux-gnueabi/
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 at 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
Signature · 3 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
Quoted 43 lines · Heiko Schocher
Hello Tom,
Am 04.12.2017 um 20:09 schrieb Tom Rini:
Quoted 19 lines · Stephen Warren
Quoted 7 lines · Tom Rini
Quoted 3 lines
Move the warning to an error as we have been promising would happen in this release.
Quoted 5 lines
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.
Quoted 8 lines
Quoted 4 lines
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).
Quoted 4 lines
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:
Quoted 8 lines
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
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
In reply to Stephen WarrenHello Tom, Stephen,
Am 04.12.2017 um 20:02 schrieb Stephen Warren:
Quoted 7 lines · Tom Rini
Quoted 2 lines
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-4.9.0-nolibc_arm-unknown-linux-gnueabi.tar.xz
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 ...
Quoted 3 lines
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
Signature · 3 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
Quoted 31 lines · Heiko Schocher
Hello Tom, Stephen,
Am 04.12.2017 um 20:02 schrieb Stephen Warren:
Quoted 8 lines · Tom Rini
Quoted 2 lines
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 armDownloading 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-4.9.0-nolibc_arm-unknown-linux-gnueabi.tar.xz
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] $
Quoted 1 line
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!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171205/98d8a969/attachment.sig>
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
In reply to Stephen WarrenQuoted 10 lines · Stephen Warren
Quoted 2 lines · Tom Rini
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).
Quoted 1 line
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.
PATCH 1/1 arm: Make gcc 6.0 or later a hard requirement now.
Quoted 7 lines · Dr. Philipp Tomsich
Quoted 7 lines · Stephen Warren
Quoted 2 lines · Tom Rini
Move the warning to an error as we have been promising would happen in this release.
Quoted 6 lines
Quoted 3 lines
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.