summaryrefslogtreecommitdiff
path: root/scripts/build/cc/100-gcc.sh
AgeCommit message (Collapse)AuthorFilesLines
2015-11-30gcc: CLooG should be optional for configureBryan Hundven1-2/+6
Because >= gcc-5.x does not require cloog, it should not be forced on the command line arguments for configure if graphite is enabled. Make CLooG optionally added, if it is needed (aka: <= gcc-4.9). Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-30PPL: Remove support for PPL and CLooG/PPLBryan Hundven1-18/+0
Now that versions of gcc that required PPL are no longer supported ( >= gcc-4.5.x AND <= gcc-4.7.x ) ...we no longer require PPL or CLooG/PPL. This commit: * Removes PPL * Removes CLooG/PPL * Updates the documentation * Updates build script for CLooG and GCC * Removes PPL and CLooG/PPL from scripts/addToolVersion.sh and scripts/showSamples.sh * Adds ISL to scripts/addToolVersion.sh and scripts/showSamples.sh I know that sounds like a lot for one commit, but it was all kind of inter-tangled. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-30gcc: Remove gcc <= 4.7.xBryan Hundven1-21/+6
As per #222, in crosstool-NG >= 1.23.0, we will only support: [upstream supported gcc versions] - 1 As of this writing, these versions are: * 5.2.0 * 4.9.3 * 4.8.5 (the -1, since development on 4.8.x is now closed) I plan to keep 4.8.5 around because of some architectures having issues with over-optimization or just faulty optimization in the 4.9.x and possibly newer versions. I also cleaned up a requirement for glibc to depend on >= gcc-4.6.x for >= glibc-2.20, but since the lowest gcc we support after this change is >= 4.8.5, this condition can go away. Patches for older gcc versions are removed in the next commit. This closes #222 Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-22Clang: Use {C,CXX}FLAG -fbracket-depth=512 for GCC buildRay Donnelly1-0/+13
https://llvm.org/bugs/show_bug.cgi?id=19650 https://gcc.gnu.org/ml/gcc/2014-05/msg00014.html Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
2015-11-17consistency: Use exported variables of required toolsBryan Hundven1-22/+22
We check for apps: * make * sed * grep * awk * libtool/libtoolize * install * patch * and more ...during configure. Our scripts should be consistent about using the variables that define where the found tool was found. Of course, we do hard-link these tools in buildtools, but that should be a backup for the components we are building. Our scripts should always use the tools we find. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-13xtensa: add support for the configurable Xtensa architecture.Chris Zankel1-0/+4
The Xtensa processor architecture is a configurable, extensible, and synthesizable 32-bit RISC processor core. Processor and SOC vendors can select from various processor options and even create customized instructions in addition to a base ISA to tailor the processor for a particular application. Because of the configurability, the build process requires one additional step for gcc, binutils, and gdb to update the default configuration. These configurations are packed into an 'overlay' tar image, and are simply untarred on top of the default configuration during the build. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2015-11-11Use install-strip target for gcc optionallyIlya Lyubimov1-1/+5
2015-10-27Clean up *.la after installing compiler/libraries.Alexey Neyman1-0/+19
Having *.la in the installation directory breaks ltrace: in ltrace, libtool somehow considers libsupc++ to be an "accessory library" and does not add -lsupc++ to the link flags. Neither Ubuntu, nor RedHat include *.la files into their packages for libstdc++. Signed-off-by: Alexey Neyman <stilor@att.net>
2015-10-09Using "all" and "install" targets in do_gcc_core_backend if configured.Jasmin Jessich1-9/+47
- New configurations: - CC_GCC_TARGET_FINAL: Use the default targets "all" and "install" for the final compiler for bare metal. - Adding parameter "build_step" to function do_gcc_core_backend: do_gcc_core_backend is used for the core compiler and in case of bare metal for the final compiler, too. To have better control over the parameters for the final compiler "build_step" is used. - Used for proper logging. - Use CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY or CT_CC_GCC_EXTRA_CONFIG_ARRAY. - If CT_CC_GCC_TARGET_FINAL is set and the final compiler is build then the make targets for the final compiler are used ("all", "install"). Signed-off-by: Jasmin Jessich <jasmin@anw.at>
2015-10-07Merge pull request #187 from jasmin-j/sync_ltoBryan Hundven1-0/+2
Synchronize CC_GCC_USE_LTO parameter setting II
2015-10-07Merge pull request #184 from jasmin-j/add_gcc_env_arrayBryan Hundven1-2/+7
Add additional environment variables for gcc build.
2015-10-07Merge pull request #182 from jasmin-j/add_missing_lib_optsBryan Hundven1-0/+15
Adding missing if/else blocks in do_gcc_core_backend.
2015-09-24Synchronize CT_CC_GCC_USE_LTO parameter setting in do_gcc_backend with the oneJasmin Jessich1-0/+2
from do_gcc_core_backend, by adding "--enable-lto"/"--disable-lto". Signed-off-by: Jasmin Jessich <jasmin@anw.
2015-09-21Added additional environment variables for gcc build (make) with new optionJasmin Jessich1-2/+7
GCC_EXTRA_ENV_ARRAY. Signed-off-by: Jasmin Jessich <jasmin@anw.at>
2015-09-21Removed doubled setting of --disable-libmudflap in do_gcc_core_backend.Jasmin Jessich1-1/+0
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
2015-09-21Adding missing if/else blocks in do_gcc_core_backend for CT_CC_GCC_LIBSSP,Jasmin Jessich1-0/+15
CT_CC_GCC_HAS_LIBQUADMATH and CT_CC_GCC_LIBQUADMATH (--en/disable-libssp, --en/disable-libquadmath, --en/disable-libquadmath-support) from function do_gcc_backend. Signed-off-by: Jasmin Jessich <jasmin@anw.at>
2015-09-01Fix for issue #142:Jasmin Jessich1-3/+3
Configure for for core GCC did not use Core gcc extra config. Use now config variable CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY. Signed-off-by: Jasmin Jessich <jasmin@anw.at>
2015-06-03gcc: Remove --enable-c99Bryan Hundven1-1/+0
This option is old. GCC 4.3.x old. It isn't supported anymore, and just confuses me. I'm not planning to support 4.3.x, or really anything older then 4.7. So this option is gone to the wind. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-06-01cc: Update 100-gcc.sh for multiple compilersRay Donnelly1-70/+70
Update 100-gcc.sh to use the new config option names. Signed-off-by: Ray Donnelly <mingw.android@gmail.com> Reviewed-by: Bryan Hundven <bryanhundven@gmail.com> Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
2015-05-29multi_cc: Prepare ct-ng for multiple compilersRay Donnelly1-0/+911
This commit moves gcc.sh to 100-gcc.sh to accomodate for other cross-compilers that crosstool-ng might be able to build. The first, to come soon, is llvm/clang. Signed-off-by: Ray Donnelly <mingw.android@gmail.com> Reviewed-by: Bryan Hundven <bryanhundven@gmail.com> Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
generated by cgit v0.10.2-6-g49f6 at 2024-04-25 15:26:39 (GMT)