[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[Tom Rini]

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[Tom Rini]

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!

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[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":-(

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

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

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[Heiko Schocher]

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

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[Heiko Schocher]

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[Dr. Philipp Tomsich]

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[Peter Robinson]

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[Tom Rini]

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

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!

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

[U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

[Stephen Warren]

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.