Commit Graph

182 Commits

Author SHA1 Message Date
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
Yann E. MORIN"
61ce016e46 cc/gcc: build multilib
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-11-23 23:51:07 +01:00
Yann E. MORIN"
92744ca68f cc/gcc: add option to use system zlib
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-12-31 16:23:27 +01:00
Zhenqiang Chen
f8d8029026 cc/gcc: Apply CT_CC_GCC_DISABLE_PCH to do_cc_core.
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-18 11:32:50 +08:00
Zhenqiang Chen
e16b3b9e52 cc/gcc: handle NLS option
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-17 18:00:28 +08:00
Yann E. MORIN"
74d555b2c3 scripts: add support for building manuals
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-11-16 10:06:21 +13:00
Yann E. MORIN"
53e8799ece cc/gcc: speed up the build a little bit
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-09-14 12:59:17 +02:00
Yann E. MORIN"
e6c749113f scripts, cc/gcc: do not fail on existing symlinks or build.log
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-07-12 23:52:24 +02:00
Yann E. MORIN"
5e3015a71c cc/gcc: do not build libgomp or libmudflap in the core steps
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-04-15 00:09:59 +02:00
Yann E. MORIN"
b491627228 cc/gcc: fix passing args with spaces when calling core gcc
Spaces in arguments to the core gcc backend were not handled.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-04-15 00:05:53 +02:00
Yann E. MORIN"
69f9485343 cc/gcc: fix non-MIPS builds
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-07-03 22:32:36 +02:00
Yann E. MORIN"
d2d948a4ad cc/gcc: add MIPS spercific configure options
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-27 18:04:50 +02:00
Yann E. MORIN"
71d5c495e9 cc/gcc: add option for linker hash style
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-27 15:15:00 +02:00
Yann E. MORIN"
9c8bde853c cc/gcc: add build-id option
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-27 13:52:15 +02:00
Yann E. MORIN"
7197a56ae6 cc/gcc: remove --enable-symver option
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-28 23:46:04 +02:00
Benoît THÉBAUDEAU"
d147fbb201 kconfig: prepend CT-NG's version tag to PKGVERSION
"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-06-03 17:21:56 +02:00
Yann E. MORIN"
b4620c6640 cc/gcc: fix a misleading FIXME
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-31 01:30:54 +02:00
Benoît THÉBAUDEAU"
35fe8a047d gcc: promote PKGVERSION and BUGURL options to toolchain level
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-31 20:12:35 +02:00
Benoît THÉBAUDEAU"
338d4b8b4d scripts: fix broken variable name
This patch fixes a config variable name missing its 'CT_' prefix.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
2011-05-24 14:15:47 +02:00
Yann E. MORIN"
c4bb88466e config: rename variables that are arrays
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-18 23:00:46 +02:00
Yann E. MORIN"
b00e501d7c scripts: interpret *_EXTRA_CONFIG config variables arrays
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-05-15 18:51:40 +02:00
Yann E. MORIN"
784d534d28 cc/gcc: fix linking with static PPL 0.11+
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-28 01:07:31 +02:00
Yann E. MORIN"
951a749ffb cc/gcc: fix building core when building statically
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-27 00:09:42 +01:00
Yann E. MORIN"
babb494db3 cc/gcc: log even more
Also log variable assignement for single commands.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-03-20 01:17:27 +01:00
Yann E. MORIN"
83a004e2c4 cc/gcc: add versions from Linaro
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-02-17 22:29:33 +01:00
Yann E. MORIN"
adbf0ff180 cc/gcc: enable plugins if needed
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>
2011-01-28 18:53:37 +01:00
Yann E. MORIN"
49ab32ffe2 scripts: PARALLELMFLAGS is evil, rename
The reunification of the glibc/eglibc code paths exposed a nasty
bug in the glibc build: use of PARALLELMFLAGS breaks the build.

See the explanations in that bug report against FC6:
    https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=212111

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2011-01-22 22:35:43 +01:00
Yann E. MORIN"
e5ded6e946 cc/gcc: build lto-plugin if binutils' gold is built
To properly enable LTO with gold, gcc has to install a plugin that gold
uses to handle the LTO information.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-12-29 17:58:35 +01:00
Bryan Hundven"
1ad4399072 cc/gcc: build bare-metal gcc statically
- add a new parameter to do_cc_core: build_statically=[yes|no]
- pass build_statically=yes in core_pass_2 when doing bare_metal
- fix handling the static / static libstdc++ / static complibs stuff
- add a commment to keep both blocks (in core and final) in sync

Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-12-09 18:55:59 +01:00
Bryan Hundven"
118a6a5f98 cc/gcc: build final gcc statically
If the global static option is set, then build the final gcc statically.

Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-12-09 18:55:42 +01:00
Yann E. MORIN"
5ddca154bb Merge. 2010-10-24 22:03:53 +02:00
Yann E. MORIN"
8b275095e0 Revert #a09246191120: cc/gcc: fix C++ headers location
This was intended as a fix for g++ not finding its headers,
but it breaks in othe horrible ways. So just revert it.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-24 22:03:47 +02:00
Anthony Foiani
92898249bd scripts: add "FILE" and "CFG" debug levels.
I ran into some minor difficulties looking through the build log for a
particular file: I wasn't interested in seeing it unpacked, but only
when it is built or installed.  Adding these two levels allows me to
differentiate between those cases.

[Yann E. MORIN: Those are blind log levels, and are used only to search
 in the build-log afterward.]

Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
2010-10-22 22:02:57 +02:00
Yann E. MORIN"
2b912ba840 cc/gcc: fix 128-bit long doubles option
Spotted by Arnaud LACOMBE:
  http://sourceware.org/ml/crossgcc/2010-10/msg00122.html

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-20 15:25:38 +02:00
Yann E. MORIN"
cbd352f9ac cc/gcc: fix C++ headers location
In case we build the C++ compiler, we have to tell gcc where to put the C++
headers, or else it will try to # put it in prefix/tuple/include, which we
make a symlink to sysroot/usr/include during the build, and that we delete
(the symlink!) after the build, but gcc will not look in sysroot/usr/inlcude
for C++ headers by default.

Implements a fix suggested by: Bryan Hundven <bryanhundven@gmail.com>

Reported-by: Anthony Foiani <anthony.foiani@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-08 23:37:12 +02:00
Yann E. MORIN"
b17f8707c1 cc/gcc: add an option to enable/disable build of libssp
libssp is the run-time Stack-Smashing Protection library.
It can be usefull to have or miss, depends...

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-09 11:38:04 +02:00
Yann E. MORIN"
8922def6b4 cc/gcc: add an option to enable/disable build of libgomp
libgomp is the GNU implementation of the OpenMP API.
It can be usefull to have or miss, depends...

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-08 23:58:58 +02:00
Yann E. MORIN"
416eb29198 cc/gcc: add option to enable 128-bit long doubles
Needed by some PPC targets, at least.
Requires gcc 4.2+ (noticed by Arnaud LACOMBE).

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-09 22:49:28 +02:00
Yann E. MORIN"
8b0af28c69 cc/gcc: fix enabling/disabling LTO
There is a ./configure option for that.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-10-08 23:51:38 +02:00
Yann E. MORIN"
9176074aec cc/gcc: disable complibs if not selected
Force gcc to not link with some companion libraries when
there are not needed (because selected-out).

There is no option to tell gcc *not* to build the Graphite and/or
LTO stuff. They *will* be built if gcc finds the suitable companion
libraries. If we do not provide them, but the host has them, then
gcc *will* find them, and link with them.

Consider the following:
- host has suitable PPL and CLooG (eg. Debian Squeeze)
- user wants to build gcc>=4.4
- user de-selects GRAPHITE
- gcc will find the hosts PPL and CLooG, and will use them
- the user moves the toolchain to an older host that does
  not have them (eg. Debian Lenny)
- the toolchain fails, when it was properly setup not to

So, explicitly tell gcc *not* to use unneeded companion libs.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-12 23:51:25 +02:00
Yann E. MORIN"
d34a5ec7d8 cc/gcc: do not force use of non-vital companion libraries
While GMP and MPFR are required by gcc>=4.3 (to build the frontends),
and MPC is required by gcc>=4.5, the other libs are not. If they are
present then gcc will enable advanced features; if they are missing,
then gcc will (should) simply disable those features.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-09-12 20:54:54 +02:00
Darcy Watkins
f30a7df9c9 cc/gcc: with static ppl, correctly link with libm
On some Fedora boxen (at least FC13), it is also required
to link with libm when static ppl is used.
2010-08-05 18:19:07 +02:00
Johannes Stezenbach
143f02e0ce cc/gcc: add option to compile against static libstdc++, for gcc-4.4 and newer
Idea and know-how taken from CodeSourcery build script.

Normal build:
  $ ldd arm-unknown-linux-uclibcgnueabi-gcc
	linux-gate.so.1 =>  (0xb77f3000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb76e8000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb75a1000)
	libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb757a000)
	/lib/ld-linux.so.2 (0xb77f4000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb755c000)

CC_STATIC_LIBSTDCXX=y:
  $ ldd arm-unknown-linux-uclibcgnueabi-gcc
	linux-gate.so.1 =>  (0xb7843000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb76e6000)
	/lib/ld-linux.so.2 (0xb7844000)

I made CC_STATIC_LIBSTDCXX default=y since I think
it is always desirable.

Signed-off-by: Johannes Stezenbach <js@sig21.net>
2010-07-29 19:47:16 +02:00
Yann E. MORIN"
8bb436dad1 cc/gcc: add option to enable/disable libmudflap
For some scenarii, libmudflap is not very usefull
or can break the build. Make in an optioon that
defaults to 'N' to be on the safe side.

For the core gcc-s, there is absolutely no need
to build libmidflap.

Idea from: Bernhard Pfund <bernhard@chapter7.ch>
2010-07-28 23:55:10 +02:00
Yann E. MORIN"
61ebaa97ca cc/gcc: make sjlj config option a tristate
A tristate fits better here than a choice.
2010-07-28 23:53:09 +02:00
Bart vdr. Meulen
25bb99693a complibs: fix using static companion libraries
When building a cross-compiler for a target which uses a file extension for
binaries the symbolic link to cc is not created correctly because the lookup
of the gcc binary is done in a incorrect path

Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
2010-07-19 23:16:02 +02:00
Yann E. MORIN"
b81d232a9b kernel: add mingw
Add the option to build a cross-compiler for kernel type 'mingw'.
The resulting cross-compiler can be used to build applications on a Linux host
that can be run on a Windows target.

Compiler is build using the mingwrt and w32-api packages aviable from the
MinGW project (http://sourceforge.net/projects/mingw).

The windows headers (w32-api package) are extracting with the kernel_headers
step The libraries and other headers from both packages are build and
installed in the various steps of libc

Signed-off-by: Bart vdr Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: fix kernel headers comment, don't "return 0"]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
2010-07-11 21:36:20 +02:00
Yann E. MORIN"
4144845579 cc/gcc: gcc-4.4 does not use MPC
As reported by Johannes Stezenbach, see thread at:
  http://sourceware.org/ml/crossgcc/2010-07/msg00017.html
2010-07-10 15:25:10 +02:00
Yann E. MORIN"
8b8f2c17ba cc/gcc: add option do disable PCH
In some cases, using Pre-Compiled Headers breaks the build.
Ass an option to disable building the PCH, as suggested by:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
2010-06-17 21:26:23 +02:00
Yann E. MORIN"
656dae57eb cc/gcc: baremetal requires a two-pass process
Here, we implement a highly ugly hack. I'm not proud of that one...

To build the libstdc++ library, the compiler requires the C library. In
case we build for non-baremetal, this is normally handled by the final
step, later.

But in the case of bare-metal, we never go through the final step (because
it does not work, and it seems complex enough to make it work), so the
baremetal compilers are issued out of the core step.
2010-06-13 23:38:37 +02:00
Yann E. MORIN"
399e7f8f8a cc/gcc: store core build rules in an array
Using an array makes it easier to add new rules.
Besides, it is easy to expand from build rules to install rules
2010-06-13 20:43:02 +02:00
Yann E. MORIN"
3983fe1184 cc/gcc: implement default for core options 2010-06-13 20:31:42 +02:00
Yann E. MORIN"
7b3c12d9a3 cc/gcc: fix headers copy for core static 2010-06-13 20:25:00 +02:00
Titus von Boxberg
d2d3c15c14 cc/gcc: Make usage of --enable-target-optspace configurable
Optionally configure to compile gcc-internal libs with -Os.

yann.morin.1998@anciens.enib.fr:
Rename the config options, it is in the GCC /namespace/.
2010-05-24 16:34:55 +02:00
Remy Bohmer
9c6c090d7b cc/gcc: use proper host compiler for canadian bare-metal
While compiling a canadian toolchain for host=mingw32, build=linux,
target=m68k-elf the build fails because in this step of the gcc build
the Host compiler is used in this stage with the build-flags for the
build system. This results in an error where the header <sys/wait.h>
cannot be found.
This problem happens at least in the GCC-4.3.x and GCC-4.4.x range.

This is solved by passing the proper compilers on the Make cmd-line

Signed-off-by: Remy Bohmer <linux@bohmer.net>
2010-04-09 21:04:37 +02:00
Bart vdr. Meulen
76ae48462a cc/gcc: allow building a canadian bare-metal compiler
Previous addition of the canadian cross compiler did not allow
to build a baremetal only variant, no reason why this is not
allowed

Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
2010-04-20 10:06:04 +02:00