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>
Plugins are shared objects, and when building a toolchain statically,
the gcc build system breaks havok (although there is no hard technical
reasons it should not be possible)...
And consequently, do not enable plugin supoprt in binutils.
Reported-by: Thomas Spurden <thomas@ado.is-a-geek.net>
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>
Directly select-ing the required companion libraries means we can not
disable them. That's OK for now, as we systematically build them when
they are required.
But with distros coming up-to-speed, we will need to disable the build
later-on.
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>
If threads are disabled in libc, we don't want to enable them in the
final compiler. Doing so pass the configure stage, but fails latter on
a missing <pthread.h>.
Moreover, we don't want to build libgomp if threads are disabled; its
configure script would fails anyway.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
For every components where it makes sense, use bash arrays (instead
of a string with space-separated values) to store the options pased
to ./configure.
