ExternalVendorCode/crosstool-ng
1
0
Fork 0
mirror of https://github.com/crosstool-ng/crosstool-ng.git synced 2024-12-22 22:22:23 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
b03575409e
crosstool-ng/config/cc/gcc.in

370 lines
7.8 KiB
Plaintext
Raw Normal View History

Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
# Compiler options
config: fix recursive deps The latest kconfig stuff is more stringent when it comes to validating the dependency of the symbols. It is no longer possible to have a symbol depend on itself (such as our construct for arch/cc/libc/... was doing). Fix our generated-file infrastructure to avoid these situations when the new kconfig stuff will be merged (in a following changeset). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-05-08 17:02:44 +00:00
#
## select CC_SUPPORT_CXX
## select CC_SUPPORT_FORTRAN
## select CC_SUPPORT_JAVA
## select CC_SUPPORT_ADA
## select CC_SUPPORT_OBJC
## select CC_SUPPORT_OBJCXX
##
## help gcc is the full-blown GNU compiler. This is what most people will choose.
## help
## help gcc supports many languages, a powerful code parser, optimised binary
## help output, and lots of other features.
Generate the choice menu for C compilers, the same way arch, kernels and C libraries are generated. /trunk/kconfig/kconfig.mk | 6 6 0 0 ++++++ /trunk/config/cc/gcc.in | 13 13 0 0 +++++++++++++ /trunk/config/cc.in | 31 3 28 0 +++---------------------------- 3 files changed, 22 insertions(+), 28 deletions(-)
2008-10-13 16:58:52 +00:00
cc/gcc: hide Linaro options by default It can be quite confusing for a new-comer to find strange version numbers for gcc, so hide the Linaro versions by default. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-26 21:04:22 +00:00
config CC_GCC_SHOW_LINARO
bool
prompt "Show Linaro versions (EXPERIMENTAL)"
depends on EXPERIMENTAL
help
Linaro is maintaining some advanced/more stable/experimental versions
of gcc, especially for the ARM architecture.
Those versions have not been blessed by the gcc comunity (nor have they
been cursed either!), but they look to be pretty much stable, and even
more stable than the upstream versions. YMMV...
If you do not know what this Linaro stuff is, then simply say 'n' here,
and rest in peace. OTOH, if you know what you are doing, you will be
able to use and enjoy :-) the Linaro versions by saying 'y' here.
Linaro: http://www.linaro.org/
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
choice
bool
Get rid of the core cc selection. It is now the same as the final compiler.
2007-08-15 10:14:43 +00:00
prompt "gcc version"
scripts: add new version at top of choice Add new versions at the top of the choice menu, not at the bottom.
2009-09-13 16:38:06 +00:00
# Don't remove next line
# CT_INSERT_VERSION_BELOW
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
cc/gcc: update Linaro GCC revisions to 2012.01 Update Linaro GCC with the latest available revisions. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
2012-01-13 11:24:55 +00:00
config CC_V_linaro_4_6_2012_01
cc/gcc: add linaro 4.6 pre-release Before gcc 4.6 was released, Linaro has a pre-release available. Include that version in the config list. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:06:53 +00:00
bool
cc/gcc: update Linaro GCC revisions to 2012.01 Update Linaro GCC with the latest available revisions. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
2012-01-13 11:24:55 +00:00
prompt "linaro-4.6-2012.01 (EXPERIMENTAL)"
cc/gcc: hide Linaro options by default It can be quite confusing for a new-comer to find strange version numbers for gcc, so hide the Linaro versions by default. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-26 21:04:22 +00:00
depends on CC_GCC_SHOW_LINARO
cc/gcc: add linaro 4.6 pre-release Before gcc 4.6 was released, Linaro has a pre-release available. Include that version in the config list. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:06:53 +00:00
select CC_GCC_4_6
cc/gcc: Add gcc-4.6.2 Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-10-26 21:25:13 +00:00
config CC_V_4_6_2
bool
prompt "4.6.2 (EXPERIMENTAL)"
depends on EXPERIMENTAL
select CC_GCC_4_6
cc/gcc: Update gcc versions Add gcc 4.6.1, 4.3.6, and 4.5.3. Move 4.4.6 version string so that it is in order. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-06-27 19:40:23 +00:00
config CC_V_4_6_1
bool
prompt "4.6.1 (EXPERIMENTAL)"
depends on EXPERIMENTAL
select CC_GCC_4_6
cc/gcc: add 4.6.0 Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-26 21:00:05 +00:00
config CC_V_4_6_0
bool
prompt "4.6.0 (EXPERIMENTAL)"
depends on EXPERIMENTAL
select CC_GCC_4_6
cc/gcc: update Linaro GCC revisions to 2012.01 Update Linaro GCC with the latest available revisions. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
2012-01-13 11:24:55 +00:00
config CC_V_linaro_4_5_2012_01
cc/gcc: add versions from Linaro Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-02-17 21:29:33 +00:00
bool
cc/gcc: update Linaro GCC revisions to 2012.01 Update Linaro GCC with the latest available revisions. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
2012-01-13 11:24:55 +00:00
prompt "linaro-4.5-2012.01 (EXPERIMENTAL)"
cc/gcc: hide Linaro options by default It can be quite confusing for a new-comer to find strange version numbers for gcc, so hide the Linaro versions by default. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-26 21:04:22 +00:00
depends on CC_GCC_SHOW_LINARO
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_5
cc/gcc: add versions from Linaro Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-02-17 21:29:33 +00:00
cc/gcc: Update gcc versions Add gcc 4.6.1, 4.3.6, and 4.5.3. Move 4.4.6 version string so that it is in order. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-06-27 19:40:23 +00:00
config CC_V_4_5_3
bool
prompt "4.5.3 (EXPERIMENTAL)"
depends on EXPERIMENTAL
select CC_GCC_4_5
cc/gcc: Add gcc 4.5.2 Add gcc 4.5.2. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2010-12-29 01:00:21 +00:00
config CC_V_4_5_2
bool
prompt "4.5.2 (EXPERIMENTAL)"
depends on EXPERIMENTAL
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_5
cc/gcc: Add gcc 4.5.2 Add gcc 4.5.2. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2010-12-29 01:00:21 +00:00
cc/gcc: 4.5.1 is out! Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2010-08-01 01:56:43 +00:00
config CC_V_4_5_1
bool
prompt "4.5.1 (EXPERIMENTAL)"
depends on EXPERIMENTAL
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_5
cc/gcc: 4.5.1 is out! Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2010-08-01 01:56:43 +00:00
cc/gcc: add 4.5.0
2010-04-15 20:35:22 +00:00
config CC_V_4_5_0
bool
prompt "4.5.0 (EXPERIMENTAL)"
depends on EXPERIMENTAL
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_5
cc/gcc: add 4.5.0
2010-04-15 20:35:22 +00:00
cc/gcc: add versions from Linaro Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-02-17 21:29:33 +00:00
config CC_V_linaro_4_4_2011_02_0
bool
prompt "linaro-4.4-2011.02-0 (EXPERIMENTAL)"
cc/gcc: hide Linaro options by default It can be quite confusing for a new-comer to find strange version numbers for gcc, so hide the Linaro versions by default. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-26 21:04:22 +00:00
depends on CC_GCC_SHOW_LINARO
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_4
cc/gcc: add versions from Linaro Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-02-17 21:29:33 +00:00
cc/gcc: add latest version Propagate the gcc-4.4.5 patchset to the newly added gcc-4.4.6. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-04-16 20:01:35 +00:00
config CC_V_4_4_6
bool
prompt "4.4.6"
cc/gcc: fix complibs dependency Since the gcc configuration changes, the way to select the dependent companion libraries has changed. The addToolVersion script was not updated to match, and a new gcc version was added with this script. Fix the gcc version; the script will be updated in a subsequent changeset. Reported-by: Xun Li <lxfind@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-05-08 08:52:21 +00:00
select CC_GCC_4_4
cc/gcc: add latest version Propagate the gcc-4.4.5 patchset to the newly added gcc-4.4.6. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-04-16 20:01:35 +00:00
cc/gcc: add 4.4.5 Add 4.4.5, propagate patchset from 4.4.4. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-09 21:28:39 +00:00
config CC_V_4_4_5
bool
prompt "4.4.5"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_4
cc/gcc: add 4.4.5 Add 4.4.5, propagate patchset from 4.4.4. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-09 21:28:39 +00:00
cc/gcc: add latest version Add 4.4.4 and forward-port patchset from 4.4.3
2010-05-16 17:41:53 +00:00
config CC_V_4_4_4
bool
cc/gcc: add 4.4.5 Add 4.4.5, propagate patchset from 4.4.4. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-09 21:28:39 +00:00
prompt "4.4.4"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_4
cc/gcc: add latest version Add 4.4.4 and forward-port patchset from 4.4.3
2010-05-16 17:41:53 +00:00
cc/gcc: add latest 4.4.3, propagate patchset from 4.4.2
2010-01-24 21:53:51 +00:00
config CC_V_4_4_3
bool
cc/gcc: remove EXPERIMENTAL for gcc-4.4
2010-01-31 11:22:54 +00:00
prompt "4.4.3"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_4
cc/gcc: add latest 4.4.3, propagate patchset from 4.4.2
2010-01-24 21:53:51 +00:00
cc/gcc: add latest 4.4.2 version as EXPERIMENTAL
2009-10-20 21:41:11 +00:00
config CC_V_4_4_2
bool
cc/gcc: remove EXPERIMENTAL for gcc-4.4
2010-01-31 11:22:54 +00:00
prompt "4.4.2"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_4
cc/gcc: add latest 4.4.2 version as EXPERIMENTAL
2009-10-20 21:41:11 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_4_1
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
bool
cc/gcc: remove EXPERIMENTAL for gcc-4.4
2010-01-31 11:22:54 +00:00
prompt "4.4.1"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_4
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_4_0
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
bool
cc/gcc: remove EXPERIMENTAL for gcc-4.4
2010-01-31 11:22:54 +00:00
prompt "4.4.0"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_4
Introduce an OBSOLETE config option, to mask-out legacy stuff.
2007-05-06 13:42:10 +00:00
cc/gcc: Update gcc versions Add gcc 4.6.1, 4.3.6, and 4.5.3. Move 4.4.6 version string so that it is in order. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-06-27 19:40:23 +00:00
config CC_V_4_3_6
bool
prompt "4.3.6"
select CC_GCC_4_3
cc/gcc: add 4.3.5 4.3.5 is the latest 4.3 version, and probably the last one. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-19 16:37:18 +00:00
config CC_V_4_3_5
bool
prompt "4.3.5"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_3
cc/gcc: add 4.3.5 4.3.5 is the latest 4.3 version, and probably the last one. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-19 16:37:18 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_3_4
Introduce an OBSOLETE config option, to mask-out legacy stuff.
2007-05-06 13:42:10 +00:00
bool
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
prompt "4.3.4"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_3
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_3_3
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
bool
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
prompt "4.3.3"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_3
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_3_2
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
bool
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
prompt "4.3.2"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_3
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_3_1
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
bool
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
prompt "4.3.1"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_3
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_2_4
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
bool
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
prompt "4.2.4"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_2
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_2_3
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
bool
config: mark now old versions as being OBSOLETE These versions are kept for the upcoming release, but they will be removed from the next release if they are not used.
2009-10-28 18:15:50 +00:00
prompt "4.2.3 (OBSOLETE)"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_2
config: mark now old versions as being OBSOLETE These versions are kept for the upcoming release, but they will be removed from the next release if they are not used.
2009-10-28 18:15:50 +00:00
depends on OBSOLETE
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_2_2
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
bool
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
prompt "4.2.2"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_2
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_2_1
Add gcc-4.1.2 and update associated patches.
2007-03-04 22:56:04 +00:00
bool
config: mark now old versions as being OBSOLETE These versions are kept for the upcoming release, but they will be removed from the next release if they are not used.
2009-10-28 18:15:50 +00:00
prompt "4.2.1 (OBSOLETE)"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_2
config: mark now old versions as being OBSOLETE These versions are kept for the upcoming release, but they will be removed from the next release if they are not used.
2009-10-28 18:15:50 +00:00
depends on OBSOLETE
Add gcc-4.1.2 and update associated patches.
2007-03-04 22:56:04 +00:00
Add gcc-4.2.0 (EXPERIMENTAL) and some patches vampirised from buildroot (302 rediffed against 4.2.0).
2007-05-20 09:27:05 +00:00
config CC_V_4_2_0
bool
config: mark now old versions as being OBSOLETE These versions are kept for the upcoming release, but they will be removed from the next release if they are not used.
2009-10-28 18:15:50 +00:00
prompt "4.2.0 (OBSOLETE)"
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_4_2
config: mark now old versions as being OBSOLETE These versions are kept for the upcoming release, but they will be removed from the next release if they are not used.
2009-10-28 18:15:50 +00:00
depends on OBSOLETE
Add gcc-4.2.0 (EXPERIMENTAL) and some patches vampirised from buildroot (302 rediffed against 4.2.0).
2007-05-20 09:27:05 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_1_2
Add gcc-4.2.1.
2007-07-29 19:15:27 +00:00
bool
config: mark now old versions as being OBSOLETE These versions are kept for the upcoming release, but they will be removed from the next release if they are not used.
2009-10-28 18:15:50 +00:00
prompt "4.1.2 (OBSOLETE)"
depends on OBSOLETE
Add gcc-4.2.1.
2007-07-29 19:15:27 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_4_0_4
Add gcc-4.2.4, with patches propagated from 4.2.3. /trunk/config/cc/gcc.in | 5 5 0 0 +++++ 1 file changed, 5 insertions(+)
2008-07-19 12:17:26 +00:00
bool
config: mark now old versions as being OBSOLETE These versions are kept for the upcoming release, but they will be removed from the next release if they are not used.
2009-10-28 18:15:50 +00:00
prompt "4.0.4 (OBSOLETE)"
depends on OBSOLETE
Add gcc-4.2.4, with patches propagated from 4.2.3. /trunk/config/cc/gcc.in | 5 5 0 0 +++++ 1 file changed, 5 insertions(+)
2008-07-19 12:17:26 +00:00
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
config CC_V_3_4_6
config/gcc: re-order versions Move the gcc-4.3.4 version to its place.
2009-08-07 16:21:29 +00:00
bool
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
prompt "3.4.6 (OBSOLETE)"
depends on OBSOLETE
config/gcc: re-order versions Move the gcc-4.3.4 version to its place.
2009-08-07 16:21:29 +00:00
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
endchoice
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
config CC_GCC_4_2
bool
select CC_GCC_4_2_or_later
cc/gcc: fix thread-less final gcc build If threads are disabled in libc, we don't want to enable them in the final compiler. Doing so pass the configure stage, but fails latter on a missing <pthread.h>. Moreover, we don't want to build libgomp if threads are disabled; its configure script would fails anyway. Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2010-04-07 16:35:22 +00:00
config CC_GCC_4_2_or_later
bool
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
config CC_GCC_4_3
bool
select CC_GCC_4_3_or_later
select CC_GCC_USE_GMP_MPFR
gcc: add a CC_GCC_HAS_PKGVERSION_BUGURL option This patch adds a blind option CC_GCC_HAS_PKGVERSION_BUGURL to test the support of --with-pkgversion and --with-bugurl by GCC's configure. Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-31 17:55:59 +00:00
select CC_GCC_HAS_PKGVERSION_BUGURL
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
Add support for building toolchains with gcc-4.4 snapshots. Initial patch by Dmitry PLOTNIKOV: http://sourceware.org/ml/crossgcc/2009-03/msg00053.html It [the toolchain] uses current ct-ng (nightly snapshot 20090324, latest release 1.3.2 work also), glibc 2.9 (from CVS), binutils 2.19 and latest snapshot of GCC 4.4.0 (as of March 20, 2009). We have successfully built linux kernel 2.6.29 and a lot of other stuff with this toolchain. Here's the patch that adds GCC 4.4.0 to the ct-ng menu and enables it to download a 4.4.0 snapshot from ftp. Patch was adpated by me, mostly to better fit the configuration layout. /trunk/scripts/build/cc/gcc.sh | 34 22 12 0 ++++++++++++++++++++++------------ /trunk/config/cc/gcc.in | 35 30 5 0 ++++++++++++++++++++++++++++++----- 2 files changed, 52 insertions(+), 17 deletions(-)
2009-03-26 18:47:34 +00:00
config CC_GCC_4_3_or_later
bool
cc/gcc: fix thread-less final gcc build If threads are disabled in libc, we don't want to enable them in the final compiler. Doing so pass the configure stage, but fails latter on a missing <pthread.h>. Moreover, we don't want to build libgomp if threads are disabled; its configure script would fails anyway. Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2010-04-07 16:35:22 +00:00
select CC_GCC_4_2_or_later
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
config CC_GCC_4_4
bool
select CC_GCC_4_4_or_later
cc/gcc: fix use of companion libraries
2010-03-05 17:55:25 +00:00
select CC_GCC_USE_GMP_MPFR
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_HAS_GRAPHITE
gcc: add a CC_GCC_HAS_PKGVERSION_BUGURL option This patch adds a blind option CC_GCC_HAS_PKGVERSION_BUGURL to test the support of --with-pkgversion and --with-bugurl by GCC's configure. Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-31 17:55:59 +00:00
select CC_GCC_HAS_PKGVERSION_BUGURL
Add support for building toolchains with gcc-4.4 snapshots. Initial patch by Dmitry PLOTNIKOV: http://sourceware.org/ml/crossgcc/2009-03/msg00053.html It [the toolchain] uses current ct-ng (nightly snapshot 20090324, latest release 1.3.2 work also), glibc 2.9 (from CVS), binutils 2.19 and latest snapshot of GCC 4.4.0 (as of March 20, 2009). We have successfully built linux kernel 2.6.29 and a lot of other stuff with this toolchain. Here's the patch that adds GCC 4.4.0 to the ct-ng menu and enables it to download a 4.4.0 snapshot from ftp. Patch was adpated by me, mostly to better fit the configuration layout. /trunk/scripts/build/cc/gcc.sh | 34 22 12 0 ++++++++++++++++++++++------------ /trunk/config/cc/gcc.in | 35 30 5 0 ++++++++++++++++++++++++++++++----- 2 files changed, 52 insertions(+), 17 deletions(-)
2009-03-26 18:47:34 +00:00
gcc-4.4: - remove snapshots - add gcc-4.4.0 release as EXPERIMENTAL -------- diffstat follows -------- /trunk/config/cc/gcc.in | 21 4 17 0 ++++----------------- 1 file changed, 4 insertions(+), 17 deletions(-)
2009-05-03 21:12:26 +00:00
config CC_GCC_4_4_or_later
Add support for building toolchains with gcc-4.4 snapshots. Initial patch by Dmitry PLOTNIKOV: http://sourceware.org/ml/crossgcc/2009-03/msg00053.html It [the toolchain] uses current ct-ng (nightly snapshot 20090324, latest release 1.3.2 work also), glibc 2.9 (from CVS), binutils 2.19 and latest snapshot of GCC 4.4.0 (as of March 20, 2009). We have successfully built linux kernel 2.6.29 and a lot of other stuff with this toolchain. Here's the patch that adds GCC 4.4.0 to the ct-ng menu and enables it to download a 4.4.0 snapshot from ftp. Patch was adpated by me, mostly to better fit the configuration layout. /trunk/scripts/build/cc/gcc.sh | 34 22 12 0 ++++++++++++++++++++++------------ /trunk/config/cc/gcc.in | 35 30 5 0 ++++++++++++++++++++++++++++++----- 2 files changed, 52 insertions(+), 17 deletions(-)
2009-03-26 18:47:34 +00:00
bool
cc/gcc: simplify the _or_later stuff
2010-02-04 14:18:46 +00:00
select CC_GCC_4_3_or_later
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
config CC_GCC_4_5
bool
select CC_GCC_4_5_or_later
select CC_GCC_USE_GMP_MPFR
select CC_GCC_USE_MPC
cc/gcc: do not force use of non-vital companion libraries While GMP and MPFR are required by gcc>=4.3 (to build the frontends), and MPC is required by gcc>=4.5, the other libs are not. If they are present then gcc will enable advanced features; if they are missing, then gcc will (should) simply disable those features. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-12 18:54:54 +00:00
select CC_GCC_HAS_GRAPHITE
cc/gcc: cleanup the _or_later logic So far, we've had a version always select appropriate _or_later option, which in turn would select all previous _or_later options. Because the dependencies on companion libs were cumulative, that was working OK. But the upcoming 4.6 will no longer depend on libelf, so we can't keep the cumulative scheme we've been using so far. Have each release family select the corresponding dependencies, instead of relying on selecting previous _or_later. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27 23:05:18 +00:00
select CC_GCC_HAS_LTO
gcc: add a CC_GCC_HAS_PKGVERSION_BUGURL option This patch adds a blind option CC_GCC_HAS_PKGVERSION_BUGURL to test the support of --with-pkgversion and --with-bugurl by GCC's configure. Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-31 17:55:59 +00:00
select CC_GCC_HAS_PKGVERSION_BUGURL
cc/gcc: add build-id option Add an option to configure gcc with --enable-linker-build-id. Reported-by: Bryan Hundven <bryanhundven@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-06-27 11:52:15 +00:00
select CC_GCC_HAS_BUILD_ID
cc/gcc: fix use of companion libraries
2010-03-05 17:55:25 +00:00
cc/gcc: add support for 4.5.0 or later versions starting with 4.5.0, gcc requires libelf.
2010-04-15 20:35:18 +00:00
config CC_GCC_4_5_or_later
bool
select CC_GCC_4_4_or_later
cc/gcc: do not force use of non-vital companion libraries While GMP and MPFR are required by gcc>=4.3 (to build the frontends), and MPC is required by gcc>=4.5, the other libs are not. If they are present then gcc will enable advanced features; if they are missing, then gcc will (should) simply disable those features. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-12 18:54:54 +00:00
cc/gcc: prepare for upcoming 4.6 gcc 4.6 will no longer depend on libelf. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-19 15:01:40 +00:00
config CC_GCC_4_6
bool
select CC_GCC_4_6_or_later
select CC_GCC_USE_GMP_MPFR
select CC_GCC_USE_MPC
select CC_GCC_HAS_GRAPHITE
select CC_GCC_HAS_LTO
gcc: add a CC_GCC_HAS_PKGVERSION_BUGURL option This patch adds a blind option CC_GCC_HAS_PKGVERSION_BUGURL to test the support of --with-pkgversion and --with-bugurl by GCC's configure. Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-31 17:55:59 +00:00
select CC_GCC_HAS_PKGVERSION_BUGURL
cc/gcc: add build-id option Add an option to configure gcc with --enable-linker-build-id. Reported-by: Bryan Hundven <bryanhundven@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-06-27 11:52:15 +00:00
select CC_GCC_HAS_BUILD_ID
cc/gcc: prepare for upcoming 4.6 gcc 4.6 will no longer depend on libelf. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-19 15:01:40 +00:00
config CC_GCC_4_6_or_later
bool
select CC_GCC_4_5_or_later
cc/gcc: do not force use of non-vital companion libraries While GMP and MPFR are required by gcc>=4.3 (to build the frontends), and MPC is required by gcc>=4.5, the other libs are not. If they are present then gcc will enable advanced features; if they are missing, then gcc will (should) simply disable those features. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-12 18:54:54 +00:00
config CC_GCC_HAS_GRAPHITE
bool
cc/gcc: enable plugins if needed Enabling plugins in binutils is not enough, and gcc also needs to be ./configured with --enable-plugins, although this is not documented anywhere... :-/ Reported-by: karthik duraisami <kdconstant@hotmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-01-28 17:53:37 +00:00
# The way LTO works is a bit twisted.
# See: http://gcc.gnu.org/wiki/LinkTimeOptimization#Requirements
# Basically:
# - if binutils has plugins: LTO is handled by ld/gold by loading
# the plugin when linking
# - if binutils does not have plugins: LTO is handled by collect2
# In any case, LTO support does not depend on plugins, but takes
# advantage of it
cc/gcc: do not force use of non-vital companion libraries While GMP and MPFR are required by gcc>=4.3 (to build the frontends), and MPC is required by gcc>=4.5, the other libs are not. If they are present then gcc will enable advanced features; if they are missing, then gcc will (should) simply disable those features. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-12 18:54:54 +00:00
config CC_GCC_HAS_LTO
bool
cc/gcc: add support for 4.5.0 or later versions starting with 4.5.0, gcc requires libelf.
2010-04-15 20:35:18 +00:00
gcc: add a CC_GCC_HAS_PKGVERSION_BUGURL option This patch adds a blind option CC_GCC_HAS_PKGVERSION_BUGURL to test the support of --with-pkgversion and --with-bugurl by GCC's configure. Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-31 17:55:59 +00:00
config CC_GCC_HAS_PKGVERSION_BUGURL
bool
cc/gcc: add build-id option Add an option to configure gcc with --enable-linker-build-id. Reported-by: Bryan Hundven <bryanhundven@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-06-27 11:52:15 +00:00
config CC_GCC_HAS_BUILD_ID
bool
cc/gcc: add option for linker hash style Add an option to specify the hash type that gcc will ask the linker to use. It is a provision for the upcoming 4.7, as no version currently supports it. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-06-27 13:15:00 +00:00
# For the upcoming 4.7 ?
# None have linker-hash-style support for now...
config CC_GCC_HAS_LNK_HASH_STYLE
bool
cc/gcc: enable plugins if needed Enabling plugins in binutils is not enough, and gcc also needs to be ./configured with --enable-plugins, although this is not documented anywhere... :-/ Reported-by: karthik duraisami <kdconstant@hotmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-01-28 17:53:37 +00:00
# Only enable gcc's support for plugins if binutils has it as well
# They are usefull only when doing LTO, but it does no harm enabling
# them even without LTO.
config CC_GCC_ENABLE_PLUGINS
bool
depends on BINUTILS_PLUGINS
cc/gcc: do not build plugins for static toolchains Plugins are shared objects, and when building a toolchain statically, the gcc build system breaks havok (although there is no hard technical reasons it should not be possible)... And consequently, do not enable plugin supoprt in binutils. Reported-by: Thomas Spurden <thomas@ado.is-a-geek.net> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-02-22 22:27:42 +00:00
depends on ! STATIC_TOOLCHAIN
cc/gcc: enable plugins if needed Enabling plugins in binutils is not enough, and gcc also needs to be ./configured with --enable-plugins, although this is not documented anywhere... :-/ Reported-by: karthik duraisami <kdconstant@hotmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-01-28 17:53:37 +00:00
default y
# If binutils installs gold, enable support for gold in gcc
config CC_GCC_GOLD
bool
depends on BINUTILS_GOLD_INSTALLED
default y
cc/gcc: fix use of companion libraries
2010-03-05 17:55:25 +00:00
config CC_GCC_USE_GMP_MPFR
bool
complibs: introduce a two-stage select Directly select-ing the required companion libraries means we can not disable them. That's OK for now, as we systematically build them when they are required. But with distros coming up-to-speed, we will need to disable the build later-on. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-03 21:11:27 +00:00
select GMP_NEEDED
select MPFR_NEEDED
cc/gcc: fix use of companion libraries
2010-03-05 17:55:25 +00:00
cc/gcc: gcc-4.4 does not use MPC As reported by Johannes Stezenbach, see thread at: http://sourceware.org/ml/crossgcc/2010-07/msg00017.html
2010-07-10 13:25:10 +00:00
config CC_GCC_USE_PPL_CLOOG
cc/gcc: fix use of companion libraries
2010-03-05 17:55:25 +00:00
bool
complibs: introduce a two-stage select Directly select-ing the required companion libraries means we can not disable them. That's OK for now, as we systematically build them when they are required. But with distros coming up-to-speed, we will need to disable the build later-on. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-03 21:11:27 +00:00
select PPL_NEEDED
select CLOOG_NEEDED
Add support for building toolchains with gcc-4.4 snapshots. Initial patch by Dmitry PLOTNIKOV: http://sourceware.org/ml/crossgcc/2009-03/msg00053.html It [the toolchain] uses current ct-ng (nightly snapshot 20090324, latest release 1.3.2 work also), glibc 2.9 (from CVS), binutils 2.19 and latest snapshot of GCC 4.4.0 (as of March 20, 2009). We have successfully built linux kernel 2.6.29 and a lot of other stuff with this toolchain. Here's the patch that adds GCC 4.4.0 to the ct-ng menu and enables it to download a 4.4.0 snapshot from ftp. Patch was adpated by me, mostly to better fit the configuration layout. /trunk/scripts/build/cc/gcc.sh | 34 22 12 0 ++++++++++++++++++++++------------ /trunk/config/cc/gcc.in | 35 30 5 0 ++++++++++++++++++++++++++++++----- 2 files changed, 52 insertions(+), 17 deletions(-)
2009-03-26 18:47:34 +00:00
cc/gcc: do not force use of non-vital companion libraries While GMP and MPFR are required by gcc>=4.3 (to build the frontends), and MPC is required by gcc>=4.5, the other libs are not. If they are present then gcc will enable advanced features; if they are missing, then gcc will (should) simply disable those features. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-12 18:54:54 +00:00
config CC_GCC_USE_MPC
cc/gcc: add support for 4.5.0 or later versions starting with 4.5.0, gcc requires libelf.
2010-04-15 20:35:18 +00:00
bool
complibs: introduce a two-stage select Directly select-ing the required companion libraries means we can not disable them. That's OK for now, as we systematically build them when they are required. But with distros coming up-to-speed, we will need to disable the build later-on. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-03 21:11:27 +00:00
select MPC_NEEDED
cc/gcc: do not force use of non-vital companion libraries While GMP and MPFR are required by gcc>=4.3 (to build the frontends), and MPC is required by gcc>=4.5, the other libs are not. If they are present then gcc will enable advanced features; if they are missing, then gcc will (should) simply disable those features. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-12 18:54:54 +00:00
config CC_GCC_USE_LIBELF
bool
complibs: introduce a two-stage select Directly select-ing the required companion libraries means we can not disable them. That's OK for now, as we systematically build them when they are required. But with distros coming up-to-speed, we will need to disable the build later-on. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-03 21:11:27 +00:00
select LIBELF_NEEDED
cc/gcc: add support for 4.5.0 or later versions starting with 4.5.0, gcc requires libelf.
2010-04-15 20:35:18 +00:00
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
config CC_VERSION
string
scripts: add new version at top of choice Add new versions at the top of the choice menu, not at the bottom.
2009-09-13 16:38:06 +00:00
# Don't remove next line
# CT_INSERT_VERSION_STRING_BELOW
cc/gcc: update Linaro GCC revisions to 2012.01 Update Linaro GCC with the latest available revisions. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
2012-01-13 11:24:55 +00:00
default "linaro-4.6-2012.01" if CC_V_linaro_4_6_2012_01
cc/gcc: Add gcc-4.6.2 Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-10-26 21:25:13 +00:00
default "4.6.2" if CC_V_4_6_2
cc/gcc: Update gcc versions Add gcc 4.6.1, 4.3.6, and 4.5.3. Move 4.4.6 version string so that it is in order. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-06-27 19:40:23 +00:00
default "4.6.1" if CC_V_4_6_1
cc/gcc: add 4.6.0 Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-26 21:00:05 +00:00
default "4.6.0" if CC_V_4_6_0
cc/gcc: update Linaro GCC revisions to 2012.01 Update Linaro GCC with the latest available revisions. Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
2012-01-13 11:24:55 +00:00
default "linaro-4.5-2012.01" if CC_V_linaro_4_5_2012_01
cc/gcc: Update gcc versions Add gcc 4.6.1, 4.3.6, and 4.5.3. Move 4.4.6 version string so that it is in order. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-06-27 19:40:23 +00:00
default "4.5.3" if CC_V_4_5_3
cc/gcc: Add gcc 4.5.2 Add gcc 4.5.2. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2010-12-29 01:00:21 +00:00
default "4.5.2" if CC_V_4_5_2
cc/gcc: 4.5.1 is out! Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2010-08-01 01:56:43 +00:00
default "4.5.1" if CC_V_4_5_1
cc/gcc: add 4.5.0
2010-04-15 20:35:22 +00:00
default "4.5.0" if CC_V_4_5_0
cc/gcc: add versions from Linaro Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-02-17 21:29:33 +00:00
default "linaro-4.4-2011.02-0" if CC_V_linaro_4_4_2011_02_0
cc/gcc: Update gcc versions Add gcc 4.6.1, 4.3.6, and 4.5.3. Move 4.4.6 version string so that it is in order. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-06-27 19:40:23 +00:00
default "4.4.6" if CC_V_4_4_6
cc/gcc: add 4.4.5 Add 4.4.5, propagate patchset from 4.4.4. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-09 21:28:39 +00:00
default "4.4.5" if CC_V_4_4_5
cc/gcc: add latest version Add 4.4.4 and forward-port patchset from 4.4.3
2010-05-16 17:41:53 +00:00
default "4.4.4" if CC_V_4_4_4
cc/gcc: add latest 4.4.3, propagate patchset from 4.4.2
2010-01-24 21:53:51 +00:00
default "4.4.3" if CC_V_4_4_3
cc/gcc: add latest 4.4.2 version as EXPERIMENTAL
2009-10-20 21:41:11 +00:00
default "4.4.2" if CC_V_4_4_2
[cc-gcc] Add latest versions Add gcc-4.4.1
2009-08-02 21:33:38 +00:00
default "4.4.1" if CC_V_4_4_1
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
default "4.4.0" if CC_V_4_4_0
cc/gcc: Update gcc versions Add gcc 4.6.1, 4.3.6, and 4.5.3. Move 4.4.6 version string so that it is in order. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2011-06-27 19:40:23 +00:00
default "4.3.6" if CC_V_4_3_6
cc/gcc: add 4.3.5 4.3.5 is the latest 4.3 version, and probably the last one. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-19 16:37:18 +00:00
default "4.3.5" if CC_V_4_3_5
config: re-order menu entries so that latest versions are at the top It makes better sense to have latest versions at the top of the choice entries.
2009-09-13 15:51:33 +00:00
default "4.3.4" if CC_V_4_3_4
default "4.3.3" if CC_V_4_3_3
default "4.3.2" if CC_V_4_3_2
default "4.3.1" if CC_V_4_3_1
default "4.3.0" if CC_V_4_3_0
default "4.2.4" if CC_V_4_2_4
default "4.2.3" if CC_V_4_2_3
default "4.2.2" if CC_V_4_2_2
default "4.2.1" if CC_V_4_2_1
default "4.2.0" if CC_V_4_2_0
default "4.1.2" if CC_V_4_1_2
default "4.0.4" if CC_V_4_0_4
default "3.4.6" if CC_V_3_4_6
Add the full crosstool-NG sources to the new repository of its own. You might just say: 'Yeah! crosstool-NG's got its own repo!". Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup. That means I'm putting backups in place in the afternoon. That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00
cc/gcc: move options around
2010-07-28 19:28:54 +00:00
config CC_LANG_JAVA_USE_ECJ
Patch from Enrico WEIGELT <weigelt@metux.de> to disable __cxa_atexit for those C libraries with no support (old uClibc).
2007-03-21 21:03:22 +00:00
bool
Add a new config knob for gcc: usage of SJLJ to handle exceptions. This is needed for some architectures to compile the Java frontend (eg. ARM with uClibc). /trunk/config/cc/gcc.in | 41 39 2 0 +++++++++++++++++++++++++++++++++++++++-- /trunk/scripts/build/cc_gcc.sh | 8 5 3 0 +++++--- 2 files changed, 44 insertions(+), 5 deletions(-)
2008-08-07 13:55:30 +00:00
default y
cc/gcc: move options around
2010-07-28 19:28:54 +00:00
depends on CC_LANG_JAVA
depends on CC_GCC_4_3_or_later
cc/gcc: fortran requires GMP and MPFR Even if gcc itself does not require GMP or MPFR (eg. gcc-4.2 and before don't), building the fortran frontend always required those companion libraries. Select them if the Fortran language is selected. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-31 20:19:21 +00:00
# Fortran always requires GMP+MPFR, whatever the gcc version
config CC_LANG_FORTRAN
select CC_GCC_USE_GMP_MPFR
Reference in New Issue Copy Permalink