Update Crosstool-NG to 1.17.0

Hello,

this is an update for the package crosstool-ng to 1.17.0. Yann wrote he didn't try to push the latest version of crosstool-ng to buildroot because it was to late. Here are the my try to send a patch to improve the usage of buildroot.
If something is still wrong, please let me know, this is my first contribution to buildroot.

Sp far I can test it here the build of a gcc 4.7.2 for armv6 for cxa2450x CPU from Nexperia is working here.

Regards
Carsten

From: Carsten Schoenert <[email protected]>

Updating current crosstool-ng config files to 1.17.0
crosstool-ng.config-eglibc crosstool-ng.config-glibc crosstool-ng.config-uClibc

---
 package/crosstool-ng/crosstool-ng.mk               |    2 +-
 .../crosstool-ng.config-eglibc                     |   73 ++++++++++++++-----
 .../crosstool-ng.config-glibc                      |   74 +++++++++++++++-----
 .../crosstool-ng.config-uClibc                     |   71 ++++++++++++++-----
 4 files changed, 165 insertions(+), 55 deletions(-)

index 5bc65e1..3b207a2 100644
@@ -1,4 +1,4 @@
-CROSSTOOL_NG_VERSION           = 1.16.0
+CROSSTOOL_NG_VERSION           = 1.17.0
 CROSSTOOL_NG_SOURCE            = crosstool-ng-$(CROSSTOOL_NG_VERSION).tar.bz2
 CROSSTOOL_NG_SITE              = http://crosstool-ng.org/download/crosstool-ng/
 CROSSTOOL_NG_INSTALL_TARGET    = NO

1.7.10.4

Dear Carsten Schoenert,

Thanks for doing this work. I think ct-ng now supports minimal defconfig files. Would it make sense to use that instead of full .config files in order to reduce the amount of churn when updating between ct-ng versions? Yann?

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Thomas, Carsten, All,

Indeed, but the defconfig support in crosstool-NG is not perfect yet, so I think we should keep complete .config files for this release.

The problem with defconfigs in crosstool-NG is that there is no guarantee about new symbols coming and going between versions, so this can result in strange behaviors when a new version comes out, and a defconfig from a previous version is used. Here's what may happen:

In version X, we use the latest stable 3.6 linux kernel, which is 3.6.2. This is also the absolute latest version of the kernel. So we have this
symbol: LINUX_VER_3_6_2

The user did select this version. As 3.6.3 is the latest version, it is the first item in the choice, so it does not appear in the defconfig, being the default of the choice.

Now, version X+1 is out, and the stable 3.6 kernel is updated to 3.6.7, so we get a new symbol, but the previous one no longer exists. Also, kernel 3.7 is out, so the 3.6.7 is not the latest version available.

Now, the default symbol in the choice is not 3.6.x, but 3.7.x, which is probably not what the user expected.

Thus, using the defconfig from the previous version will yield a completely different .config.

This can be even more anoying with the gcc version, as we only have one linaro release per gcc /generation/ (eg. 4.7). If the user did select the latest linaro version (eg. 4.7) which was the default of the choice, qnd the new release has a more recent mainstream version (eg. 4.8), but no corresponding linaro version, then the gcc version will be bumnped to 4.8, when the user did in fact want the linaro 4.7.

I have a pending change to fix this issue for all components, but it will go in only for the next release, and that shall make using defconfigs from a previous version relatively safe to use with a newer version.

Then, we can switch buildroot to using the ct-ng defconfigs, but until then I think it is safer to use full .config files.

Regards,
Yann E. MORIN.

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Dear Yann E. MORIN,

To me, it is also the point of using defconfig from the first place: to benefit from the new default values for configuration options that we leave undefined.

Note that the crosstool-ng.config-* don't necessarily need to be pure defconfig files: you can add a few explicit options, whose value is currently the default one, but since you don't want them to change to newer default values, you explicit their value in the defconfig. We have this for a few options in Buildroot defconfig files as well.

defconfig files do not necessarily need to be the direct output of "savedefconfig", they can be hand-edited to enforce the value of certain options.

Best regards,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Carsten> From: Carsten Schoenert <[email protected]> Carsten> Updating current crosstool-ng config files to 1.17.0

 Carsten>  crosstool-ng.config-eglibc
 Carsten>  crosstool-ng.config-glibc
 Carsten>  crosstool-ng.config-uClibc

Committed, thanks.

The change to defconfig can happen later.

Carsten> #
Carsten> # C compiler
Carsten> @@ -242,6 +267,7 @@ CT_BINUTILS_EXTRA_CONFIG_ARRAY="" Carsten> CT_CC="gcc"
Carsten> CT_CC_VERSION="4.4.6"

It would also be nice to default to gcc 4.6.x to match the internal toolchain.

Bye, Peter Korsgaard

Carsten> From: Carsten Schoenert <[email protected]> Carsten> Updating current crosstool-ng config files to 1.17.0

 Carsten>  crosstool-ng.config-eglibc
 Carsten>  crosstool-ng.config-glibc
 Carsten>  crosstool-ng.config-uClibc

Unfortunately it doesn't seem to build here (ppl compilation issue):

[ERROR] /home/peko/source/buildroot/testctng/build/build-toolchain/.build/src/ppl-0.10.2/src/Interval.defs.hh:451:86: error: 'f_info' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
[ALL ] In file included from /home/peko/source/buildroot/testctng/build/build-toolchain/.build/src/ppl-0.10.2/src/Interval.defs.hh:980:0

Yann, Carsten - Any ideas? Googling around seems to suggest that this is related to a host-gcc 4.7.x issue, but people are quite likely to be using that nowadays, so what to do? Build with -fpermissive?

Bye, Peter Korsgaard

Peter, All,

Yes, it requires -fpermissive to build with gcc-4.7.

Someone spoke about providing a patch to this effect on the crossgcc ML, but nothing so far.

I am using a Debian squeeze that has a gcc-4.4, so I can't test it. I'll try in a wheezy chroot soonish.

Regards,
Yann E. MORIN.

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Hello Yann, Hello Peter,

Am 09.12.2012 21:37, schrieb Yann E. MORIN:

I remember I ran into similar problems with ppl-010.2 while I try to find a setup for a arm crosscompiler with gcc4.7.1. After choosing ppl-0.11.2 and setting the switch -fpermissive the build was successful (but of course with a lot warnings while global settings for LDFLAGS).

Right, GCC greater 4.6 are more strict while syntax checking, so without -fpermissive actual compiler in Debian wheezy will give up. But for me is setting -fpermisse just a temporaly solution. Newer GCCs will always give up in such cases and that's correct.

No need for that. :-)
Wheezy use the current GCC 4.7.2 and the sources need a patch to correct the source or the switch -fpermissive.

Because I don't know exactly how to patch the source (I don't have take a deep look into it) or the Makefile for ppl-0.1x.x inside the crosstool-ng environment I can't provide some useful right now.

Regards
Carsten