summaryrefslogtreecommitdiff
path: root/scripts/build/cc
AgeCommit message (Collapse)AuthorFilesLines
2016-08-23multilib: Determine which options may pass through.Alexey Neyman1-51/+167
On some arches (e.g. MIPS) the options like -mabi do not work if specified more than once (see the comment in 100-gcc.sh). Therefore, we need to determine which of the options produced by <arch>.sh can be passed to multilib builds and which must be removed (i.e., which options vary among the multilibs). This presents a chicken-and-egg problem. GCC developers, in their infinite wisdom, do not allow arbitrary multilib specification to be supplied to GCC's configure. Instead, the target (and sometimes some extra options) determine the set of multilibs - which may include different CPUs, different ABIs, different endianness, different FPUs, different floating-point ABIs, ... That is, we don't know which parts vary until we build GCC and ask it. So, the solution implemented here is: - For multilib builds, start with empty CT_ARCH_TARGET_CFLAGS/LDFLAGS. - For multilib builds, require core pass 1. Pass 1 does not build any target binaries, so at that point, our target options have not been used yet. - Provide an API to modify the environment variables for the steps that follow the current one. - As a part of multilib-related housekeeping, determine the variable part of multilibs and filter out these options; pass the rest into CT_TARGET_CFLAGS/LDFLAGS. This still does not handle extra dependencies between GCC options (like -ma implying -mcpu=X -mtune=Y, etc.) but I feel that would complicate matters too much. Let's leave this until there's a compelling case for it. Also, query GCC's sysroot suffix for targets that use it (SuperH, for example) - the default multilib may not work if the command line specifies the default option explicitly (%sysroot_suffix_spec is not aware of multilib defaults). Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23crosstool-NG.sh.in: Don't make lots of symlinks to lib folderRay Donnelly1-31/+43
For 4 different folders: ${CT_PREFIX_DIR} ${CT_SYSROOT_DIR} ${CT_SYSROOT_DIR}/usr ${CT_PREFIX_DIR}/${CT_TARGET} .. symlinks from 'lib32' and 'lib64' to 'lib' were created. This was untidy and incorrect for multilib (the bitness of the libraries in 'lib32' and 'lib64' will not be the same) We can not know which folders this toolchain configuration will require at this time so let them be created on-demand instead. Changed by Alexey Neyman: original change removed too much; we still need to create the default directories because the os directories are based off them (e.g. `lib/../lib64'). Signed-off-by: Ray Donnelly <mingw.android@gmail.com> Signed-off-by: Alexey Neyman <stilor@att.net>
2016-06-10gcc: Add --with-multilib-list optionRay Donnelly1-0/+6
Written by Bryan Hundven. Modified by Alexey Neyman to actually add the option to gcc.in. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com> Signed-off-by: Ray Donnelly <mingw.android@gmail.com> Signed-off-by: Alexey Neyman <stilor@att.net>
2016-06-10Enable multiarch support in pass-1 GCC.Alexey Neyman1-3/+12
By default, it is 'auto' - which means, it is enabled if there are multilibs directories detected in the installation location for libgcc. Thus, it is not detected for pass-1 GCC: the installation location is empty at this point. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-03-15scripts/build/cc: pass FLAGS_FOR_TARGET in do_gcc_core_backendMax Filippov1-0/+3
Pass CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET and LDFLAGS_FOR_TARGET to gcc configure in do_gcc_core_backend as they may be used to build libstdc++ for bare-metal target. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2016-01-18Remove GCC dependency to libelfMatthias Weisser1-4/+0
As crosstools-ng only support GCC >= 4.8 we do not need libelf for gcc. GCC dropped this dependency with 4.6. Signed-off-by: Matthias Weisser <m.weisser.m@gmail.com>
2016-01-07gcc: fix previous commitBryan Hundven1-1/+1
In a5057713a0394d189adc8b9abb0eb65592ecfc49 ...I forgot to add a line continuation at the break in the 'if' statement. Reported-by: asavah <asavah@avh.od.ua> Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-01-06gcc: Fix CC_GCC_ENABLE_CXX_FLAGS for mode=baremetalBryan Hundven1-0/+6
When creating a baremetal toolchain, CC_GCC_ENABLE_CXX_FLAGS has no effect. This closes #298 Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-01-06gcc: remove CC_GCC_EXTRA_ENV_ARRAYBryan Hundven1-8/+3
I was noticing that $extra_user_env was inconsistently used in 100-gcc.sh. I don't feel comfortable having just any make flag or environment variable passed to make from a config file. If a specific option needs to be passed to make for gcc, then a specific kconfig option should be added for that make flag/option/env. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-01-06gcc: Sync backend functionsBryan Hundven1-36/+35
The two gcc backend functions are getting very close to being duplicated code. To help in the process of merging the two backends, this change syncronizes the two functions so they are easier to diff. This commit has no functional changes. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-01-03gcc: Add new linaro download pathBryan Hundven1-3/+4
It seems that linaro is changing where they release, again. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-12-08Whitespace: We don't use tabs in shell or kconfig filesBryan Hundven1-10/+10
We indent by multiples of 4. This change cleans up whitespace in offending files. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-12-08scripts: Update usage of CT_GetCustomBryan Hundven1-7/+2
This commit updates the build scripts to match the new usage of CT_GetCustom from the previous change. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-30gcc: Gnu OpenMP support depends on threadingBryan Hundven1-1/+0
Instead of checking if thread support is enabled during the build, move the check to kconfig-time. Since if threading support is not availble, libgomp should not be available either. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
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/+0
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>
2015-04-07Only create ${CT_TARGET}-cc${ext} symlink if ${CT_TARGET}-gcc existsJohannes Pfau1-2/+6
Without this canadion cross builds create invalid symlinks: When the code in do_cc_core_backend is called there is no ${CT_TARGET}-gcc in the install directory. Therefore ext is empty and we create a link to ${CT_TARGET}-gcc. The final compiler step then installs ${CT_TARGET}-gcc.exe and creates a working ${CT_TARGET}-cc.exe symlink but we still keep the invalid link as well. Signed-off-by: Johannes Pfau <johannespfau@gmail.com>
2015-02-02scripts/*/*.sh: prioritize http downloadsBryan Hundven1-3/+5
Prirotize http downloads before ftp downloads. By having http download first, those using proxy will work with the current download mechnism. This tells me that that mechnism needs to be updated. (proxy support and/or kconfig toggles) closes #3 Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-01-16gcc: Add Linaro GCC 4.9-2015.01 and GCC 4.8-2014.11Cristoforo Cataldo1-12/+13
This commit allows to choose, download and build latest Linaro GCC: - gcc-linaro-4.9-2015.01 - gcc-linaro-4.8-2014.11 Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>
2015-01-01cc/gcc: Remove copyheaders toggle in do_cc_core_backend, make defaultDavid Holsgrove1-8/+2
Canadian Cross compile for baremetal fails with error; checking for the value of EOF... configure: error: computing EOF failed which is due to libstdc++ configure not being able to find stdio.h Having all modes of the core compiler copyheaders from CT_HEADERS_DIR (in combination with previous patch for newlib to add a do_libc_start_files function to copy into the CT_HEADERS_DIR) resolves this. Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
2014-12-09gcc and gdb: fix fetching linaro builds (part three)Bryan Hundven1-1/+2
Yes, I missed the backslash which messed up the linaro stuff. The more I look at this code, I feel it needs to be refactored a bit. So I'll come back to this in the future and clean it up. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2014-12-09gcc and gdb: fix fetching linaro builds (part two)Bryan Hundven1-1/+1
It's not my day. linaro_version is a filter. If it is not a linaro toolchain, it will just be CT_{CC,GDB}_VERSION. If it is a linaro toolchain, CT_{CC,GDB}_VERSION will be prefixed with 'linaro-' and will not match linaro_version, as linaro_version will just have the part after 'linaro-'. This *really* fixes the issue :sigh: Thanks again to @elsonwei for being right the first time! Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2014-12-09gcc and gdb: fix fetching linaro buildsBryan Hundven1-2/+2
linaro_version and linaro_series are defined but not set if we are not configured for linaro builds. Therefore we need to default them to "" (null string). As reported by @elsonwei Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2014-12-08scripts: Update download locationsBryan Hundven1-9/+10
This change updates the download locations to default to the official download site. For gcc and gdb, also separate out the linaro download locations so that if you are downloading the linaro variant, it skips trying to download from the official gcc mirror. This commit closes #3 Signed-off-by: Bryan Hundven <bryanhundven@gmail.com> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-31cc/gcc: add option to enable/disable libsanitizerYann E. MORIN1-3/+7
libsaniotizer requires a few headers that are not in uClibc, for example. Also, it is only available for native threads (NPTL under glibc.) Finally, it is only available starting with gcc-4.8. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-07-19cc/gcc: avoid passing --enable-multilib (take 2)Cody P Schafer1-3/+4
The previous patch (cset b61a1b1, cc/gcc: avoid passing --enable-multilib) only fixed the core backend, and missed the final backend. This patch does the same as b61a1b1, but for the final backend. Signed-off-by: Cody P Schafer <dev@codyps.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-05-10cc/gcc: allow CC_EXTRA_CONFIG_ARRAY on baremetalCody Schafer1-1/+5
The final bare-metal compiler is built using the core backend. Currently the core uses the CC_CORE_EXTRA_CONFIG_ARRAY variable. While this works as supposed to, this can leave the user puzzled in the menuconfig, since all he can see is the core options, not the final options. Only show the core options if any of the core passes are needed, and use the final options in the core-backend if we're issuing the bare-metal compiler. Signed-off-by: Cody P Schafer <dev@codyps.com> [yann.morin.1998@free.fr: hide core options if no core pass needed; use final option in core backend if issuing the bare-metal compiler] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Message-Id: <22181e546ba746202489.1399688067@localhost> Patchwork-Id: 347586
2014-05-10cc/gcc: avoid passing --enable-multilibCody Schafer1-3/+3
Some versions of gcc have a broken --enable-multilib flag. As multilib is the default, only pass the --disable-multilib flag Signed-off-by: Cody P Schafer <dev@codyps.com> [yann.morin.1998@free.fr: make it an if-block; duplicate commit log as comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Message-Id: <5c970c1ceb22528fe28a.1399687923@localhost> Patchwork-Id: 347585
2014-05-05cc/gcc: only build required core passesYann E. MORIN"1-2/+2
We now know exactly what pass to build, so build only what is required. Reported-by: Trevor Woerner <trevor.woerner@linaro.org> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-01-04cc/gcc: add option to enable/disable decimal floatsYann E. MORIN"1-0/+10
Decimal floats need support form the C library, namely support for fenv, which is missing in uClibc for any architecture but x86/32. Add an option (a choice) to enable or disable decimal floats. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-01-04cc/gcc: set CXXFLAGS at configure gccDaniel Dittmann1-0/+2
Since gcc 4.8 C++ is also used as implementation language (see gcc release notes). Signed-off-by: "Daniel Dittmann" <ddittmann@gmx.net> Message-Id: <acc7d11bc77b30f21c5b.1388863298@bernalk.machteam> Patchwork-Id: 306883
2014-01-04cc/gcc: diable libsanitizer without NPTLYann E. MORIN"1-0/+3
gcc-4.8 comes with a new library to sanitise memory access: - heap-, stack-, and global-buffer overflow, use-after-free - data-races between threads This library requires some _np parts of the API, which are not implemented in the (old) LinuxThreads, which is still available in uClibc. Since NPTL requires a i486 or above, i386 are stuck with using LT, which precludes building the libsanitizer. Disable libsanitizer, a bit like libatomic is. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Niels Penneman <niels@penneman.org>
generated by cgit v0.10.2-6-g49f6 at 2024-05-10 16:47:13 (GMT)