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>
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>
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>
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>
- 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>
Enable definition of "Use __cxa_atexit" for bare-metal systems, if the used
libc does provide such a function. The libc configuration have to select
LIBC_PROVIDES_CXA_ATEXIT.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
This change updates the config to support multiple compilers by moving
CC_.* to CC_GCC_.* to make room for other compilers.
We also update gen_in_frags.sh to check for a default cc.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
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>
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
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>
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>
It's been some time now we've had those features, so unmark them
being experimental.
It does not mean everything is perfect, but may gather some more
testing of those features.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
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>
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>
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>
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>
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>
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>
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>
It makes sense to have all library-related config knobs in
the same place; and it makes sense to have all other misc
config knobs in the same other place.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
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>
