| Message ID | 1512263522-7584-1-git-send-email-trini@konsulko.com |
|---|---|
| State | Accepted |
| Commit | 6b867dabe84bae1e74e88f4af620c26cb793c4c2 |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [U-Boot] arm: Make gcc 6.0 or later a hard requirement now. | expand |
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, 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
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@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 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 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
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!
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.
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
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(-)