summaryrefslogtreecommitdiff
path: root/scripts/build/cc
AgeCommit message (Collapse)AuthorFilesLines
2012-05-06cc/gcc: add option to enable/disable libquadmathYann E. MORIN"1-0/+9
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-01-03cc/gcc: build core compilers for canadianYann E. MORIN"1-11/+5
Currently, we rely on an existing external cross-compiler targetting the target, to build the C library. This can pause quite a few problems if that compiler is different from the one we are building, because it could introduce some ABI issues. This patch removes this dependency, by building the core compilers as we do for standard cross, and also by building the binutils and gcc, for running on the build machine. This means we no longer need to offer the cross-sompiler selection in the menuconfig. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2012-04-02cc/gcc: add build frontendYann E. MORIN"1-2/+42
Bizarrely enough, the core gcc are not enough to be able to build a canadian cross, and a real, full cross compiler is required so that the canadian cross can be properly built... WTF?!? Sigh... Add a build-frontend, as was done for the binutils and the complibs. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-04-01cc/gcc: frontends are responsible for selecting the list of languagesYann E. MORIN"1-2/+4
Do for the final step the same as for the core step: compute the list of selected langauages from the frontend, not in the backend. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2011-08-15cc/gcc: pass the language list to the core backendYann E. MORIN"1-4/+6
As the core backend can be used to also build the bare-metal compiler, we have to tel it what languages to build. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-08-15cc/gcc: add language helper functionYann E. MORIN"1-14/+20
Add a function that prepares the language configure option. It is needed in at least two places, some commonalisation is needed. ;-) Unfortunately, it is no longer possible to print warnings about experimental languages any more. Anyway, the experimental status is clearly indicated in the menuconfig. so it should not be a surprise if the build breaks. :-/ Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-25complibs: fixup the host complibs install dirYann E. MORIN"1-3/+3
It's easier to have as much as possible stuff in the same place to ease backup/restore, and make things easier to follow. Move the host companion libraries install dir as a sub-dir of the build-tools install dir (but not directly in it, it would break for canadian or cross-native). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-25cc/gcc: cleanup the frontendsYann E. MORIN"1-35/+21
A few noop fix-ups: - fix the comments in core pass-1 - commonalise settings that can be Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-17cc/gcc: always build core compilers to run on the build machineYann E. MORIN"1-5/+5
The core compilers are used to build the C library, so they should always run on the build machine, not on the host. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2012-01-01cc/gcc: install the core compilers in the build-tools dirYann E. MORIN"1-5/+2
There really is no good reason to install the core compilers in their own places, one for each pass. We can install them with the other build tools. Also, this implies that: - there are fewer directories to save/restore - there are fewer symlinks to create for binutils - the PATH is shorter Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2012-02-27cc/gcc: Update core_prefix_dir to prefix.Zhenqiang Chen1-1/+1
core_prefix_dir is not defined. It should be prefix. Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
2011-07-24cc-gcc: the frontends are responsible for mkdir/chdirYann E. MORIN"1-17/+22
The build dir are created depending on the host (host for that specific backend, not host for the toolchain). Only the frontends know what host this is, so only the frontends can create non-ambiguous dirs. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-24cc/gcc: fix core backend's API docYann E. MORIN"1-13/+14
Make it more in line with the final backend's doc, and make it simpler as well. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-24cc/gcc: no need to build a static core pass-1 gcc for baremetalYann E. MORIN"1-11/+0
The only user of the static core compiler in pass-1 was the newlib C library. Now that it is build in a later step, we do no longer need to build a static core compiler in pass-1. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2012-02-13cc/gcc: comonalise the manuals build decisionYann E. MORIN"1-3/+7
Let the final frontend decide whether or not to build the manuals. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-17cc/gcc: do not use the core pass-2 to build the baremetal compilerYann E. MORIN"1-9/+16
In case we build a baremetal compiler, use the standard passes: - core_cc is used to build the C library; - as such, it is meant to run on build, not host; - the final compiler is meant to run on host; As the current final compiler step can not build a baremetal compiler, call the core backend from the final step. NB: Currently, newlib is built during the start_files pass, so we have to have a core compiler by then... Once we can build the baremetal compiler from the final cc step, then we can move the newlib build to the proper step, and then get rid of the core pass-1 static compiler... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-17cc/gcc: add the backend/frontend infra for final gccYann E. MORIN"1-10/+39
Currently, we issue the bare-metal compiler from the pass_1 & pass_2 core compilers, because the final gcc breaks while doing so. This implies we have to build some libces during the start_files step, instead of the standard libc step. This is the case for newlib. By adding a backend/frontend infra to the final gcc, we can abstract what backend to call: the standard backend for non-bare-metal gcc, and the core backend for bare-metal. This patch is just an no-op, it just adds the final backend and frontend without changing the way bare-metal is built, to come in a subsequent patch. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-08-23cc/gcc: add 'cflags' paramater to the core backendYann E. MORIN"1-1/+9
As the core backend is used to generate the bare-metal compiler, we need to pass it the host CFLAGS. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-17cc/gcc: add host parameter to core compiler build processYann E. MORIN"1-1/+9
Tell the core compiler what host it should run on (instead of hard-coding runing on CT_HOST). No functional change so far, switching between CT_HOST and CT_BUILD will come in a following patch. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-17cc/gcc: pass the install prefix to the core passesYann E. MORIN"1-8/+12
Currently, the discrimination on the core compilers prefixes depends on the type of core compiler to build. This is not correct, and the caller of the core backend should specify the prefix. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-17cc/gcc: pass the companion libs prefix to cc_coreYann E. MORIN"1-7/+15
In case of canadian-cross, the companion libraries are not the same for the core cc (they run on 'build') as they are for the final cc (they run on 'host'). Prepare for this differentiation (coming later), while retaining the current behavior (to use the same compblibs). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-11-20cc/gcc: rename the core backend functionYann E. MORIN"1-4/+4
Rename the core backend function to do_cc_core_backend, to make it explicit it is a backend. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-17cc/gcc: simplify calls to core backendYann E. MORIN"1-14/+44
The core backend is going to have more parameters in the upcoming patches, so it will be a bit complex to handle. Introduce an array-variable that is filled by the different code-paths with the required values. This makes the code easier to read and maintain. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2012-02-13cc/gcc: do not consume parameters when parsing themYann E. MORIN"1-3/+3
The current construct consumes the parameters while we parse them. Change this to a construct that does not consume the parameters. This has no impact on gcc, but is done for homogeneity with other components (eg. glibc). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-12-30cc/gcc: print supported multilibsYann E. MORIN"1-0/+30
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-11-23cc/gcc: build multilibYann E. MORIN"1-2/+12
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-12-31cc/gcc: add option to use system zlibYann E. MORIN"1-0/+8
In some cases, it might be desirable to use the system zlib Eg. because latest gcc seem to be totally borked when it comes to multilib, and tries to build a multilib host zlib, when it is *absolutely* *not* needed: we want mulitlib on the target, not on the host! Sigh... :-( Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-11-18cc/gcc: Apply CT_CC_GCC_DISABLE_PCH to do_cc_core.Zhenqiang Chen1-0/+2
Otherwise, users have to input --disable-libstdcxx-pch option when building bare-metal CANADIAN C++ compiler. Reviewed-by: Michael Hope Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
2011-11-17cc/gcc: handle NLS optionZhenqiang Chen1-4/+4
Add --disable-nls config when option "Enable nls" is not selected. Reviewed-by: Michael Hope Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
2011-11-15scripts: add support for building manualsYann E. MORIN"1-2/+17
Add support for building the HTML and PDF manuals for the major components. Implement for binutils, GCC, GDB, and GLIBC. Always build all manuals and install a subset. Be explicit about the subset to reduce the clutter and to avoid getting copies of common manuals like bfd from all of the sourceware based components. Downside of being explicit is that you need to update it when a new component comes along. Build the manuals as part of the last GCC build, namely 'cc' for glibc based ones and cc_core_pass_2 for baremetal. An example of the output is at: http://people.linaro.org/~michaelh/incoming/crosstool-NG/ Signed-off-by: Michael Hope <michael.hope@linaro.org> [yann.morin.1998@anciens.enib.fr: depends on ! remove docs; gold manual install] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-09-14cc/gcc: speed up the build a little bitYann E. MORIN"1-6/+6
Even if the current process is highly parallel, crosstool-NG spends most of its time in single-job steps on fast machines (with a 12-CPU system, I approximate the parallel vs. non-parallel time to be in the order os 1 to 3; that is crostool-NG spends two-thirds of its time running non-parallel jobs). Some steps to build gcc can be paralleled, gaining a litle bit of time on the whole compilation. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-12scripts, cc/gcc: do not fail on existing symlinks or build.logYann E. MORIN"1-2/+2
If the user builds a toolchain over an existing one, so, without removing CT_PREFIX_DIR, the build fails as the symlinks already exist, as does the build.log. This can also happen (for build.log) if the user first ran in download- or extract-only. Patch (with no SoB) originally from: Phil Wilshire <phil.wilshire@overturenetworks.com> Modified by me as it did not apply cleanly. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-04-14cc/gcc: do not build libgomp or libmudflap in the core stepsYann E. MORIN"1-0/+3
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-04-14cc/gcc: fix passing args with spaces when calling core gccYann E. MORIN"1-1/+1
Spaces in arguments to the core gcc backend were not handled. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-07-03cc/gcc: fix non-MIPS buildsYann E. MORIN"1-30/+34
The new MIPS-specific options are not valid for other targets. Also, move the arch-specific setting lower in the extra_config setting. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-06-27cc/gcc: add MIPS spercific configure optionsYann E. MORIN"1-0/+32
Add the following MIPS specific options when configuring gcc: --with(out)-llsc --with(out)-synci --with(out)-mips-plt --with-divide=type Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-06-27cc/gcc: add option for linker hash styleYann E. MORIN"1-0/+10
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-27cc/gcc: add build-id optionYann E. MORIN"1-0/+8
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-28cc/gcc: remove --enable-symver optionYann E. MORIN"1-4/+0
That option is coming from the original crosstool, and is not entirely understand here. Moreover, it breaks with newer gcc-s: 4.6.1 now breaks while configuring libjava (and probably some other libs as well, untested). There is an related bug report to the gcc BZ: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49555 If need be, the old behavior can be restored with: CC_CORE_EXTRA_CONFIG_ARRAY="--enable-symver=gnu" CC_EXTRA_CONFIG_ARRAY="--enable-symver=gnu" Reported-by: Bryan Hundven <bryanhundven@gmail.com> Reviewed-by: Bryan Hundven <bryanhundven@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-06-03kconfig: prepend CT-NG's version tag to PKGVERSIONBenoît THÉBAUDEAU"1-4/+4
"crosstool-NG-${CT_VERSION}" is currently the default for TOOLCHAIN_PKGVERSION, and this options is passed as is to --with-pkgversion. This patch prepends "crosstool-NG ${CT_VERSION}" to TOOLCHAIN_PKGVERSION before passing it to --with-pkgversion. Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-30cc/gcc: fix a misleading FIXMEYann E. MORIN"1-4/+4
The FIXME about the static libstdc++ is misleading; it only deserves being an INFO. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-05-31gcc: promote PKGVERSION and BUGURL options to toolchain levelBenoît THÉBAUDEAU"1-6/+10
This patch promotes the PKGVERSION and BUGURL options to toolchain level so that all toolchain components supporting them can benefit from them. These options are passed to configure through --with-pkgversion and --with-bugurl. They are supported by binutils 2.18+, gcc 4.3+, eglibc 2.9+ and gdb 7.0+. Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-24scripts: fix broken variable nameBenoît THÉBAUDEAU"1-2/+2
This patch fixes a config variable name missing its 'CT_' prefix. Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-18config: rename variables that are arraysYann E. MORIN"1-2/+2
Make it explicit that a variable is an array bu the name of the variable. It will be used later when .config gets munged to allow both multiple arguments and arguments with spaces at the same time to be passed from the configuration down to the build scripts. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-05-15scripts: interpret *_EXTRA_CONFIG config variables arraysYann E. MORIN"1-2/+2
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-27cc/gcc: fix linking with static PPL 0.11+Yann E. MORIN"1-4/+32
PPL 0.11+ installs three libs: lippl, libppl_c and libpwl. libppl_c has a dependency on libpwl (at least for watchdog stuff). While gcc correctly links with libppl and libppl_c, it does not pull libpwl in. In case of shared libs, this is not a problem, as libppl_c has a NEEDED dependency on libpwl. But for static libs, that does not work. Although libppl_c.la exists and has a correct dependency on lipwl, somehow gcc misses it. So we have to force pulling libpwl when needed. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-26cc/gcc: fix building core when building staticallyYann E. MORIN"1-2/+2
There was a mishap when cut-n-pasting code from the final step into the core step: a variable was not renamed. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-20cc/gcc: log even moreYann E. MORIN"1-2/+2
Also log variable assignement for single commands. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-02-17cc/gcc: add versions from LinaroYann E. MORIN"1-1/+15
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-01-28cc/gcc: enable plugins if neededYann E. MORIN"1-7/+4
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>
generated by cgit v0.10.2-6-g49f6 at 2024-05-02 09:34:34 (GMT)