summaryrefslogtreecommitdiff
path: root/scripts/build/cc
AgeCommit message (Collapse)AuthorFilesLines
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>
2014-01-03cc/gcc: fix gcc 4.8 build for C library without threads supportNiels Penneman1-0/+5
Signed-off-by: Niels Penneman <niels@penneman.org> Message-Id: <309df93f4354c80e05c9.1388743085@i7sb.local> Patchwork-Id: 306521
2013-11-19cc/gcc: Add Fortran support for Baremetal buildZhenqiang Chen1-0/+10
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org> [yann.morin.1998@free.fr: fix damage due to mailer] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Message-Id: <CACgzC7D5HCVS-qX=ydcQphNFH=VGgJzTdZWQWaLKAv-CdE8crA@mail.gmail.com> Patchwork-Id: 292703
2013-11-08cc/gcc: Add support for golangYann E. MORIN"1-0/+1
Signed-off-by: Richard Weinberger <richard@nod.at> Message-Id: <ca374aef944e28a6ec3c.1383921708@azrael> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2013-05-05cc/gcc: add preliminray support for 4.8Yann E. MORIN"1-10/+22
This means: - introduce the new symbols for 4.8 - do not always select PPL if graphite is selected Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru> [Dmitry did a preliminray patch to add gcc-4.8 support, which this patch is inspired from] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2013-05-13cc/gcc: Set CXX_FOR_BUILD for bare metal and canadian build.Zhenqiang Chen1-0/+1
>From 4.8, g++ is used as the default compiler to build the toolchain. Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org> Message-Id: <CACgzC7B-LQvAw3hOYhBA7b7g0H1WtH20gqXM=Y=YFO4FrnZKWQ@mail.gmail.com> Patchwork-Id: 243590
2013-05-02cc/gcc: modify to build gcc-4.8-based cross-toolsJongsung Kim1-0/+5
Building cross-tool based on gcc-4.8 fails while "Installing pass-2 core C compiler", because building libgcc.mvars needs libbacktrace.a that gcc.sh doesn't build. This patch inserts a few lines configuring, and making libbacktrace into gcc.sh to build gcc-4.8-based cross-tools successfully. Reported-by: Plotnikov Dmitry <leitz@ispras.ru> Signed-off-by: Jongsung Kim <neidhard.kim@lge.com> Message-Id: <201305031831.33395.neidhard.kim@lge.com> Patchwork-Id: 241258
2012-11-25cc/gcc: do not print 'core' or 'final'Yann E. MORIN"1-6/+6
In gcc-'s core and final passes, do not print 'core' or 'final' in log messages. We already print it in step messages. Also, as we use the core backend to build the bare-metal final gcc, it can be disturbing to read 'core' while we're in fact in 'final'. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-11-22cc: add a flag for skipping core passesYann Diorcet1-0/+8
It is used for skipping unnecessary compilation steps when the libc doesn't need to be compiled (eg. when we do not use a C library). Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com> Message-Id: <150eadb0117e697d79aa.1353625025@blackmint> Patchwork-Id: 201222
2012-11-16scripts: add BUILD/HOST extra cflags/ldflagsYann Diorcet1-2/+13
On some hosts, and for certain toolchains (eg. toolchain targetting the upcoming Darwin), it may be necessary to pass arbitrary CFLAGS and/or LDFLAGS when building the components. And necessary infrastructure: - EXTRA_{CFLAGS,LDFLAGS}_FOR_{BUILD,HOST} as config options - pass those extra flags to components Fix-up a slight typo in elf2flt at the same time (misnamed cflags). Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com> Message-Id: <d24043276c9243a35421.1353077450@macbook-smorlat.local> Patchwork-Id: 199645
2012-10-29cc/gcc: remove svn sourceYann E. MORIN"1-23/+5
Since we now have the opportunity to use a custom local directory/tarball as the source for gcc, it no longer makes sense to retrieve gcc ourselves from its subversion repository. Cc: Bryan Hundven <bryanhundven@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-10-11cc/gcc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustomDavid Holsgrove1-1/+9
CUSTOM_LOCATION config options only presented in menuconfig if component CUSTOM version selected. Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com> [yann.morin.1998@free.fr: don't patch custom directory location] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Message-Id: <f2272ac0f37cedd0bb91.1349931194@localhost.localdomain> PatchWork-Id: 190787
2012-10-13cc/gcc: do not print multilib for canadian-crossYann E. MORIN"1-10/+14
Previous import from patchwork missed one hunk (in cset #d8feb93b3e49) Apply it now. Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Patchwork-Id: 189053
2012-10-04scripts/gcc: Canadian Cross skip -print-multi-lib log outputDavid Holsgrove1-10/+15
Attempting to ${CT_TARGET}-gcc -print-multi-lib will fail In do_cc_core_backend, for the final compiler in a canadian cross baremetal, warn that multi-libs cannot be determined In do_cc_backend, for either final compiler for a canadian cross, warn that multi-libs cannot be determined (Plus fixed CT_PREFIX_DIR in do_cc_backend to be ${prefix}) Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com> Message-Id: <CAM=EW8aQDoNx-CkJHjXBoDP4iTDJ8z5hh3=KhO5UTU6rp3Pj=w@mail.gmail.com> Patchwork-Id: 189053
2012-08-22cc/gcc: Add the ability to build gcc from svnYann E. MORIN"1-23/+42
I took some of the svn functionality from eglibc. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com> [yann.morin.1998@free.fr: fix the conditional test in build script] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-08-22cc/gcc: cleanup comments from rude wordingsYann E. MORIN"1-3/+2
That comes from way back when nothing would work as expected, and I would easily get heated as soon as anything would break. Sigh, those were the old days. Apologies. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-08-04cc/gcc: remove duplicate code in core pass-1Yann E. MORIN"1-20/+6
Whatever the threading model (NPTL, LT...), we build the same core pass-1 compiler, so there is no need to have a case-esac construct. Remove now mis-leading and incorect comment. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-08-01cc/gcc: remove now useless condition-variableYann E. MORIN"1-21/+10
Both core pass-1 and -2 compilers are unconditionally built, so we no longer require a condition variable. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-08-01cc/gcc: always build core pass-1Yann E. MORIN"1-0/+9
Up until now, all conditions requiring a core pass-1 was when the threading implementation used was NPTL. So we only built the core pass-1 when NPTL was used. Now, things have changed (what? when? Dunno...), and some bare-metal canadian toolchains fail to build if a core pass-1 is not present. OTOH, a core pass-1, although not needed for non-NPTL builds, does no harm at all if it is present. So, unconditionally build a core pass-1 (but still pass conditional options to the core backend). Reported-by: Per Arnold Blaasmo <Per-Arnold.Blaasmo@atmel.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-05-09cc/gcc: do not build manuals in parallelYann E. MORIN"1-1/+1
Reported-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> Reported-by: Johannes Stezenbach <js@sig21.net> Tested-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>