Commit Graph

237 Commits

Author SHA1 Message Date
Alexey Neyman
3330ad7197 Fine-tune moving gcc libraries to sysroot.
1. Check if anything was installed outside sysroot; on some [baremetal only?]
configurations GCC doesn't install anything to ${CT_PREFIX_DIR}/${CT_TARGET}/lib.
2. We need to create <sysroot>/lib/<multilib> if it doesn't exist
(MUSL only installs in <sysroot>/usr/lib).
3. Do not move the linker scripts; elf2flt expects to find them
in gcc's dir, not sysroot.

Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-07 10:34:33 -07:00
Alexey Neyman
33fccf9838 Merge branch 'master' into x86-musl 2016-10-04 11:43:42 -07:00
Alexey Neyman
96338beeca GCC uses multi_os_dir for libgcc, not multi_dir.
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-02 18:50:41 -07:00
Alexey Neyman
75dee86653 Fix issue #449.
After building final gcc, place the libraries in non-sysroot libs
into sysroot.

Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-02 15:23:53 -07:00
Alexey Neyman
651567ff90 Add a checkbox for libmpx build.
Disable libmpx for musl builds.

Signed-off-by: Alexey Neyman <stilor@att.net>
2016-09-22 17:01:43 -07:00
Alexey Neyman
43c303c946 libc/*.sh: handle combinations of multilib root/dir.
Install startfiles for libc variants into the most specific combination
(suffixed sysroot, if applicable + suffixed multi-os dir, if
applicable). Install headers once in every suffixed sysroot (although it
seems that GCC picks up headers from top-level sysroot, GCC manual
claims that sysroot suffix affects headers search path).

In uClibc, this requires a better sanitization of the directory: it
creates symlinks from {sysroot}/usr/lib/{multi_os_dir} to
{sysroot}/lib/{multi_os_dir} and to do so, it counts the number of path
components in the libdir. This breaks if one of such components is `..'
- symlinks contain an extra `../..' then. Since such sanitization had to
be implemented anyway, use it in other places to print more sensible
directory names.

Also, fix the description of configure --host/--target per musl's
configure help message (and its actual code).

Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23 11:00:27 -07:00
Alexey Neyman
82072d0cbc multilib: Determine which options may pass through.
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-23 11:00:27 -07:00
Ray Donnelly
27fed7e5f0 crosstool-NG.sh.in: Don't make lots of symlinks to lib folder
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-08-23 11:00:27 -07:00
Ray Donnelly
aa30d0bc4f gcc: Add --with-multilib-list option
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-09 17:12:49 -07:00
Alexey Neyman
a65d8841ec Enable multiarch support in pass-1 GCC.
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-06-09 17:12:49 -07:00
Max Filippov
02d8e4a514 scripts/build/cc: pass FLAGS_FOR_TARGET in do_gcc_core_backend
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-03-15 17:14:16 +03:00
Matthias Weisser
3f05fcb52b Remove GCC dependency to libelf
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-18 16:08:23 +01:00
Bryan Hundven
0d4275e0dd gcc: fix previous commit
In a5057713a0
...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-07 10:45:33 -08:00
Bryan Hundven
a5057713a0 gcc: Fix CC_GCC_ENABLE_CXX_FLAGS for mode=baremetal
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-06 11:22:58 -08:00
Bryan Hundven
225b96ebc8 gcc: remove CC_GCC_EXTRA_ENV_ARRAY
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-06 11:07:06 -08:00
Bryan Hundven
311a78d6e1 gcc: Sync backend functions
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-06 10:59:26 -08:00
Bryan Hundven
7c7bcecd2e gcc: Add new linaro download path
It seems that linaro is changing where they release, again.

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-01-02 22:33:23 -08:00
Bryan Hundven
9f89e082c5 Whitespace: We don't use tabs in shell or kconfig files
We indent by multiples of 4.
This change cleans up whitespace in offending files.

Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-12-08 10:55:17 -08:00
Bryan Hundven
4e2227e8a5 scripts: Update usage of CT_GetCustom
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-12-08 10:55:13 -08:00
Bryan Hundven
cfd2a6b69c gcc: Gnu OpenMP support depends on threading
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-29 17:40:08 -08:00
Bryan Hundven
8b40ab0d6e gcc: CLooG should be optional for configure
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-29 17:36:58 -08:00
Bryan Hundven
0e0ecc8bcf PPL: Remove support for PPL and CLooG/PPL
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-29 17:36:58 -08:00
Bryan Hundven
2a89c32193 gcc: Remove gcc <= 4.7.x
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-29 17:36:58 -08:00
Ray Donnelly
b0743fdcda Clang: Use {C,CXX}FLAG -fbracket-depth=512 for GCC build
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-22 14:39:26 +00:00
Bryan Hundven
6f8e89cb5c consistency: Use exported variables of required tools
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-17 02:48:09 -08:00
Chris Zankel
81328ed1cb xtensa: add support for the configurable Xtensa architecture.
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-13 09:08:53 +03:00
Ilya Lyubimov
69405c3b32 Use install-strip target for gcc optionally 2015-11-11 12:29:54 +03:00
Alexey Neyman
0a050d3390 Clean up *.la after installing compiler/libraries.
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-26 18:34:06 -07:00
Jasmin Jessich
3bd86362ab Using "all" and "install" targets in do_gcc_core_backend if configured.
- 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-10 00:24:42 +02:00
Bryan Hundven
625f7e66b4 Merge pull request #187 from jasmin-j/sync_lto
Synchronize CC_GCC_USE_LTO parameter setting II
2015-10-07 13:35:44 -07:00
Bryan Hundven
9e9b9bd195 Merge pull request #184 from jasmin-j/add_gcc_env_array
Add additional environment variables for gcc build.
2015-10-07 13:32:53 -07:00
Bryan Hundven
866bff1307 Merge pull request #182 from jasmin-j/add_missing_lib_opts
Adding missing if/else blocks in do_gcc_core_backend.
2015-10-07 13:31:19 -07:00
Jasmin Jessich
9bce2dc540 Synchronize CT_CC_GCC_USE_LTO parameter setting in do_gcc_backend with the one
from do_gcc_core_backend, by adding "--enable-lto"/"--disable-lto".

Signed-off-by: Jasmin Jessich <jasmin@anw.
2015-09-25 01:32:27 +02:00
Jasmin Jessich
931248f1aa Added additional environment variables for gcc build (make) with new option
GCC_EXTRA_ENV_ARRAY.

Signed-off-by: Jasmin Jessich <jasmin@anw.at>
2015-09-22 00:21:36 +02:00
Jasmin Jessich
64a158f932 Removed doubled setting of --disable-libmudflap in do_gcc_core_backend.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
2015-09-22 00:20:19 +02:00
Jasmin Jessich
9c3248af89 Adding missing if/else blocks in do_gcc_core_backend for CT_CC_GCC_LIBSSP,
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-22 00:19:10 +02:00
Jasmin Jessich
c6f30f67f0 Fix for issue #142:
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-09-01 02:46:38 +02:00
Bryan Hundven
728b410657 gcc: Remove --enable-c99
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-03 12:26:10 -07:00
Ray Donnelly
8ce2abf57d cc: Update 100-gcc.sh for multiple compilers
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-06-02 00:01:32 +01:00
Ray Donnelly
3049c4c1e2 multi_cc: Prepare ct-ng for multiple compilers
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-05-29 21:49:32 +01:00
Johannes Pfau
586e30f726 Only create ${CT_TARGET}-cc${ext} symlink if ${CT_TARGET}-gcc exists
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-04-07 20:14:26 +02:00
Bryan Hundven
7b8d76ed56 scripts/*/*.sh: prioritize http downloads
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-02-01 21:00:14 -08:00
Cristoforo Cataldo
d90bd6f13f gcc: Add Linaro GCC 4.9-2015.01 and GCC 4.8-2014.11
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-16 22:07:44 +01:00
David Holsgrove
af731ae904 cc/gcc: Remove copyheaders toggle in do_cc_core_backend, make default
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>
2015-01-02 09:52:29 +10:00
Bryan Hundven
91cf168d76 gcc and gdb: fix fetching linaro builds (part three)
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-08 23:46:41 -08:00
Bryan Hundven
1e17619b27 gcc and gdb: fix fetching linaro builds (part two)
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-08 23:27:46 -08:00
Bryan Hundven
aee4142a9d gcc and gdb: fix fetching linaro builds
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-08 22:32:19 -08:00
Bryan Hundven
79422633cf scripts: Update download locations
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-12-08 15:03:08 -08:00
Yann E. MORIN
a56df802eb cc/gcc: add option to enable/disable libsanitizer
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-08-31 18:54:13 +02:00
Cody P Schafer
975d24cb35 cc/gcc: avoid passing --enable-multilib (take 2)
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-07-19 12:10:23 +02:00
Cody Schafer
db2872f2ac cc/gcc: allow CC_EXTRA_CONFIG_ARRAY on baremetal
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-09 19:13:49 -07:00
Cody Schafer
b61a1b13ee cc/gcc: avoid passing --enable-multilib
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-09 19:11:59 -07:00
Yann E. MORIN"
eb0da898f8 cc/gcc: only build required core passes
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-05-05 23:24:05 +02:00
Yann E. MORIN"
2ee8d1d8f2 cc/gcc: add option to enable/disable decimal floats
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-04 16:17:40 +01:00
Daniel Dittmann
ba4abe8285 cc/gcc: set CXXFLAGS at configure gcc
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-04 20:16:18 +01:00
Yann E. MORIN"
c6fd7bd2d9 cc/gcc: diable libsanitizer without NPTL
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-04 01:02:57 +01:00
Niels Penneman
89e9d9851a cc/gcc: fix gcc 4.8 build for C library without threads support
Signed-off-by: Niels Penneman <niels@penneman.org>
Message-Id: <309df93f4354c80e05c9.1388743085@i7sb.local>
Patchwork-Id: 306521
2014-01-03 10:57:48 +01:00
Zhenqiang Chen
2f94f99dd8 cc/gcc: Add Fortran support for Baremetal build
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-19 14:44:02 +08:00
Yann E. MORIN"
cf36828878 cc/gcc: Add support for golang
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-11-08 15:18:09 +01:00
Yann E. MORIN"
1dc3dd9167 cc/gcc: add preliminray support for 4.8
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-05 17:59:00 +02:00
Zhenqiang Chen
501204e8d4 cc/gcc: Set CXX_FOR_BUILD for bare metal and canadian build.
>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-13 15:00:56 +08:00
Jongsung Kim
d8988dbe0b cc/gcc: modify to build gcc-4.8-based cross-tools
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
2013-05-02 23:31:33 +00:00
Yann E. MORIN"
4e9c473337 cc/gcc: do not print 'core' or 'final'
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-25 18:22:38 +01:00
Yann Diorcet
e9920217e8 cc: add a flag for skipping core passes
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-22 23:56:58 +01:00
Yann Diorcet
b43fdf40f1 scripts: add BUILD/HOST extra cflags/ldflags
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-11-16 15:25:57 +01:00
Yann E. MORIN"
8bcd5c689c cc/gcc: remove svn source
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-30 00:30:47 +01:00
David Holsgrove
6b8740dd6d cc/gcc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustom
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-11 14:39:41 +10:00
Yann E. MORIN"
dad17e6e88 cc/gcc: do not print multilib for canadian-cross
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-13 18:26:26 +02:00
David Holsgrove
071606c0a0 scripts/gcc: Canadian Cross skip -print-multi-lib log output
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-10-04 15:59:31 +10:00
Yann E. MORIN"
8c43cdb436 cc/gcc: Add the ability to build gcc from svn
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-22 12:26:10 -07:00
Yann E. MORIN"
a7eb2dea72 cc/gcc: cleanup comments from rude wordings
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-22 18:08:39 +02:00
Yann E. MORIN"
fa0ca9dfea cc/gcc: remove duplicate code in core pass-1
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-04 23:15:02 +02:00
Yann E. MORIN"
c74fa76e4d cc/gcc: remove now useless condition-variable
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-01 19:07:37 +02:00
Yann E. MORIN"
9d64a6b29e cc/gcc: always build core pass-1
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-08-01 19:02:06 +02:00
Yann E. MORIN"
4e8f04012c cc/gcc: do not build manuals in parallel
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>
2012-05-09 18:17:17 +02:00
Yann E. MORIN"
27e8b280f9 cc/gcc: add option to enable/disable libquadmath
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2012-05-06 15:32:56 +02:00
Yann E. MORIN"
d776140189 cc/gcc: build core compilers for canadian
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-01-03 22:57:25 +01:00
Yann E. MORIN"
b485733f26 cc/gcc: add build frontend
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-02 22:54:30 +02:00
Yann E. MORIN"
6471f1598c cc/gcc: frontends are responsible for selecting the list of languages
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>
2012-04-01 19:07:11 +02:00
Yann E. MORIN"
7b360e7a22 cc/gcc: pass the language list to the core backend
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-15 22:52:51 +02:00
Yann E. MORIN"
1a7cf0ea9e cc/gcc: add language helper function
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-08-15 21:42:28 +02:00
Yann E. MORIN"
2f718dd60c complibs: fixup the host complibs install dir
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-25 19:04:17 +02:00
Yann E. MORIN"
4a8daa02e3 cc/gcc: cleanup the frontends
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-25 19:04:00 +02:00
Yann E. MORIN"
08161250ed cc/gcc: always build core compilers to run on the build machine
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>
2011-07-17 18:28:19 +02:00
Yann E. MORIN"
e960f66953 cc/gcc: install the core compilers in the build-tools dir
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-01-01 17:49:44 +01:00
Zhenqiang Chen
c6caf866f9 cc/gcc: Update core_prefix_dir to prefix.
core_prefix_dir is not defined. It should be prefix.

Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
2012-02-27 15:24:18 +08:00
Yann E. MORIN"
fec8e7b566 cc-gcc: the frontends are responsible for mkdir/chdir
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-24 19:35:24 +02:00
Yann E. MORIN"
b990202ced cc/gcc: fix core backend's API doc
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-24 19:24:02 +02:00
Yann E. MORIN"
58337ba708 cc/gcc: no need to build a static core pass-1 gcc for baremetal
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>
2011-07-24 19:33:04 +02:00
Yann E. MORIN"
f6de807fc0 cc/gcc: comonalise the manuals build decision
Let the final frontend decide whether or not to build the manuals.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2012-02-13 22:18:02 +01:00
Yann E. MORIN"
33cdb19ed5 cc/gcc: do not use the core pass-2 to build the baremetal compiler
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-17 22:43:07 +02:00
Yann E. MORIN"
40dda92f57 cc/gcc: add the backend/frontend infra for final gcc
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-07-17 22:46:47 +02:00
Yann E. MORIN"
35f50ca6c2 cc/gcc: add 'cflags' paramater to the core backend
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-08-23 21:11:26 +02:00
Yann E. MORIN"
6a29db1593 cc/gcc: add host parameter to core compiler build process
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-17 18:10:53 +02:00
Yann E. MORIN"
cf7fbfa839 cc/gcc: pass the install prefix to the core passes
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-17 17:56:22 +02:00
Yann E. MORIN"
f87a5d6d19 cc/gcc: pass the companion libs prefix to cc_core
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-07-17 17:54:21 +02:00
Yann E. MORIN"
02a77ea464 cc/gcc: rename the core backend function
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-11-20 18:08:00 +01:00
Yann E. MORIN"
e837554caa cc/gcc: simplify calls to core backend
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>
2011-07-17 15:48:27 +02:00
Yann E. MORIN"
e9de7fc0af cc/gcc: do not consume parameters when parsing them
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>
2012-02-13 21:51:48 +01:00
Yann E. MORIN"
81dc791f83 cc/gcc: print supported multilibs
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-12-30 21:43:10 +01:00