Update Linaro GCC with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <e1da9700b5ce493eeb94.1342125564@advdt005-ubuntu>
Attempt #2 at updating gcc.
This time without porting gcc 4.7.0 patches forward.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <aeffa57986d52dd7b0a8.1341290304@flambe.is-a-geek.org>
Update Linaro GCC with the latest available revisions.
The 4.7 revision is also released, but the infrastructure is not yet ready for
it in CT-NG.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
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>
Currently, we check host feature in ./configure. This works only for
cross toolchains, but not for canadian toolchains. ./configure has
absolutely no way to know what the host for the toolchain will be;
only the build scripts know.
So, move the headers & libraries checks from ./configure to the build
scripts, early enough in the build, but not before we know the host
compiler and other tools.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split gcc/gdb in two patches]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Even if gcc itself does not require GMP or MPFR (eg. gcc-4.2 and before
don't), building the fortran frontend always required those companion
libraries.
Select them if the Fortran language is selected.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This patch bumps the Linaro GCC revisions to 2011.07 when applicable.
Note that the `-0' suffix has been removed from the Linaro versioning scheme
beginning with this version.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Static liunking is not supported on Darwin, so hide the corresponding
options when the build machine is Darwin.
Reported-by: Andrea Franceschini <therealmorpheu5@gmail.com>
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: "Titus von Boxberg" <titus@v9g.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
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>
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>
Hide the staticaly linked libstdc++ option if the static libstdc++ is not
present, detected at configure time.
Add a blind option that says whether static linking is possible at all.
It defaults to 'y', but depends on the needed CONFIGURE_* options. For
now, it only depends on static libtdc++, but new dependencies can be
easily added.
Hide the global static toolchain option behind this new option.
Original patch by Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
This patch adds a blind option CC_GCC_HAS_PKGVERSION_BUGURL to test the support
of --with-pkgversion and --with-bugurl by GCC's configure.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
kconfig bools are disabled by default, so specifying 'default n' is useless and
noisy. This patch removes all occurrences of 'default n'.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Update help entries for thos variables that accept multiple
arguments with spaces (aka. array-capable variables).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
The latest kconfig stuff is more stringent when it comes to validating
the dependency of the symbols. It is no longer possible to have a symbol
depend on itself (such as our construct for arch/cc/libc/... was doing).
Fix our generated-file infrastructure to avoid these situations when the
new kconfig stuff will be merged (in a following changeset).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since the gcc configuration changes, the way to select the
dependent companion libraries has changed. The addToolVersion
script was not updated to match, and a new gcc version was
added with this script.
Fix the gcc version; the script will be updated in a subsequent
changeset.
Reported-by: Xun Li <lxfind@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move options around so it feels more organised.
Add comments to separate groups of related options.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It can be quite confusing for a new-comer to find strange
version numbers for gcc, so hide the Linaro versions by
default.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Before gcc 4.6 was released, Linaro has a pre-release available.
Include that version in the config list.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
So far, we've had a version always select appropriate _or_later option,
which in turn would select all previous _or_later options.
Because the dependencies on companion libs were cumulative, that was
working OK. But the upcoming 4.6 will no longer depend on libelf, so
we can't keep the cumulative scheme we've been using so far.
Have each release family select the corresponding dependencies, instead
of relying on selecting previous _or_later.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
