CLooG 0.18+ will use ISL instead of PPL, so we have to configure
adequately depending of which backend is in use.
The Kconfig entries will decide for us which is selected, so we
can rely on either PPL xor ISL to be selected, not both.
Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru>
[Dmitry did a preliminray patch to add ISL support,
which this patch is inspired from]
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>
ISL is used by gcc-4.8 onward for GRAPHITE, so is also used as
backend for CLooG 0.18.0 onward.
Reported-by: "Plotnikov Dmitry" <leitz@ispras.ru>
[Dmitry did a preliminray patch to add ISL, which this one is inspired from]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
[yann.morin.1998@free.fr: added newer versions released since]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <435dcc4cade342ab9ee0.1365686746@advdt005-ubuntu>
Patchwork-Id: 235741
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <14c04210a1dc18f3c678.1363295061@advdt005-ubuntu>
Patchwork-Id: 227803
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
[yann.morin.1998@free.fr: add latest versions since released]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <125b3612bbefcb57166b.1361275815@advdt005-ubuntu>
Patchwork-Id: 221686
Now we use defconfig files to store the samples, we have to be a bit more
conservatives in the symbols names, so as to avoid gigantic version bumps
when updating sub-level versions from a package.
Update samples accordingly.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Now we use defconfig files to store the samples, we have to be a bit more
conservatives in the symbols names, so as to avoid gigantic version bumps
when updating sub-level versions from a package.
For example (using fictitious versions):
- in crosstool-NG 1.17.0, we choose:
- latest gcc is gcc-linaro-4.7-2012.10, which is the default for the
choice in the menuconfig
- gcc-linaro-4.6-2012.10 is selected
- so, sample has an explicit symbol for the selected gcc version, as it
is not the default
- we update to crosstool-NG 1.18.0:
- latest gcc version is gcc-linaro-4.7-2013.01
- gcc-linaro-46 has been updated to gcc-linaro-4.6-2013.01
- as the sample now has no *valid* symbol to set the gcc version, the
default is used, while we would have expected to still use the 4.6
release from linaro, not the 4.7
Get rid of sub-level (ie. the third digit sequence in versions) from the
symbols for linaro versions.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
For some architectures, it is legit to have an alternate value in the
'architecture' part of the tuple. For example:
armv5te-*
armv7a8-*
Besides, some packages expect the tuple to reflect the arch variant
(eg. openMPI) to detect the variant's capabilities (eg. atomic
primitives).
This patch adds an option for the user to specify a suffix to be added
to the arch-part of the tuple.
Signed-off-by: Willy Tarreau <w@1wt.eu>
Message-ID: <20130120225822.GS6838@1wt.eu>
Patch-Id: 213994
[yann.morin.1998@free.fr: make it a suffix, not an override]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
kernel/linux: update revisions
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <df032717ca91dc9cc876.1358518690@advdt005-ubuntu>
Patchwork-Id: 213616
Running as root is really, really dangerous.
Add a runtime-check that refuses to build if running as root.
Can be overriden with a double switch in the menuconfig.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Well, leave the prompt as an OBSOLETE thing, scheduled to
be removed soon.
As an indication OABI lives its last days, gcc-4.8 will no
longer recognise non-EABI targets.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Toolchains that use the hard-float ABI now are to be denoted by a tuple
ending in *eabihf, while the prevbious *eabi is now an indication that
the toolchain uses the softfloat ABI.
This is purely a cosmetic thing, for distros to differentiate their
hardfloat-ABI ports from their softfloat-ABI ports.
(note: softfloat ABI does not mean that it is using softfloats; it can
be using hardfloat instructions, but using the softfloat ABI).
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>
It's been a while we've had those versions, time to unmark them being
experimental. It does not mean everything is perfect, but may gather
some more testing on those versions.
Update samples accordingly.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Well, all eglibc version we support do, and latest glibc versions
we support do.
Not all glibc versions do, but older versions simply ignore the
unrecognised ./configure flags.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Re-order the three entries in the float choice, in a more sensible
order, ie:
- all hard-float options come first, then soft-float
- options that use the FPU are marked so: hard and softfp
- options that do not use the FPU are marked so: software
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <515f9ed69f58a0af21e9.1355226920@advdt005-ubuntu>
Patchwork-Id: 205183
ppl-0.10.x does not build with gcc-4.6+, as it uses constructs that were
warnings with gcc-4.5 and before, but are now errors with gcc-4.6 and
above.
Fix that by passing -fpermissive in CFLAGS for ppl 0.10.
Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
Reported-by: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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
Rework binutils in order to provide soon binutils alternative.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971
In preparation of adding a new kernel-type, Yann D. came up
with a change in semantic on binutils/gold availability.
So far, it was architectures' responsibility to declare that
they did support binutils/gold or not. It makes much more sense
that binutils/gold declares its own availability depending on
the current architecture; after all, architectures have no way
to know wether gold supports them, while gold does know it.
Signed-off-by:Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971
In preparation of adding a new kernel-type, Yann D. came up
with a cleanup pass on the ELF/FLAT/FDPIC dependencies.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971
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
sstrip has been obsoleted for a while now, as it's still broken
for some archs, and there seems to be no incentive to fix it
upstream. Besides, the space gained with sstrip is marginal at
best.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <65c8bf534d0647ce52cd.1353320545@macbook-smorlat.local>
Patchwork-Id: 199970
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <4b669b1e51901b6ec6b1.1353009148@advdt005-ubuntu>
Patchwork-Id: 199394
Replace the 32-bit-only mingw32 with mingw-w64 that is capable
of building toolchains for both 32-bit and 64-bit Windows.
kernel/mingw: replace mingw32 with generic Windows
kernel/windows: New windows kernel supporting 32 and 64 bit arch
libc/mingw: Remove old options
patches: Remove old mingw libc options' patches
Signed-off-by: "Yann Diorcet" <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: array var in libc/mingw.sh, typos]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <b045ac08fc9eac2e5ee3.1352898499@blackmint>
Patchwork-Id: 198901
We now have the ability to use a custom location, so supporting
snapshots or custom date is no longer needed. Let the user do the
required preparation in this case.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
We now have the ability to use a custom local directory/tarball, so
it no longer makes sense to have the ability to use the CVS repository.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Change elf2flt CT_ELF2FLT_VERSION from 'head' to 'cvs' if cvs selected in config
Also remove hardcoded 'cvs-' from elf2flt component name, used in CT_Extract,
CT_Patch and as the CT_SRC_DIR location for the configure stage.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
[yann.morin.1998@free.fr: fix indentation, don't patch custom dir location]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <288db3721a37844defa5.1349931196@localhost.localdomain>
PatchWork-Id: 190789
Add an option that, when a command fails:
- starts an interactive shell with the failed command's environment
- attempts re-execution of the failed command, continues, or aborts
at user's whim.
Before starting the debug-shell, the backtrace is printed.
When exiting for an abort, the standard error message is printed.
Based on an idea and a patch from: Johannes Stezenbach <js@sig21.net>
http://sourceware.org/ml/crossgcc/2012-09/msg00144.html
Signed-off-by: Johannes Stezenbach <js@sig21.net>
[yann.morin.1998@free.fr: integrate in the fault handler]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Johannes Stezenbach <js@sig21.net>
Patchwork-Id: 191571
Patchwork-Id: 191668
Add a generic custom location infrastructure (inspired by the one in
kernel/linux) to allow the user to use custom tarballs or directories
for any component.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
[yann.morin.1998@free.fr: move config option, improve help text, fix API doc]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <131c163c69f9cc81d2be.1349931191@localhost.localdomain>
PatchWork-Id: 190784
Message-Id: <0bbaba9190a76ba97f72.1349931192@localhost.localdomain>
PatchWork-Id: 190785
kernel/linux: update revisions
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <efc60d787e571c37eef1.1349964870@advdt005-ubuntu>
PatchWork-Id: 190917
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <f87414d1b7f0d5d417b7.1348237635@advdt005-ubuntu>
PatchWork-ID: 185747
Add Microblaze architecture support.
This depends on EXPERIMENTAL, as upstream projects do not yet
include full support to build a modern microblaze compiler.
This is in the process of being updated, but is not currently
publicly accessible.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Message-Id: <9c93e18b3d68b19303f3.1348113870@localhost.localdomain>
PatchWork-ID: 185305
Currently, if downloads are forbidden, the mirror is still tried for.
Change this way:
- if downlaods forbidden, do not try neither upstream locations nor mirror
- add option to only use the mirror, and avoid upstream locations
Signed-off-by: Austin Morton <austinpmorton@gmail.com>
[yann.morin.1998@free.fr: broaden the if USE_MIRRORto enclode mirror location]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <3be58d464e5a3ed992b4.1345487432@advdt005-ubuntu>
Update Linaro GCC with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <6b26606413410c987746.1345486888@advdt005-ubuntu>
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Message-Id: <c626b7332f2b92478fda.1343045360@advdt005-ubuntu>
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>
Patches don't need to come forward, as they are in this branch.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <6fdf77081379812820e8.1341286640@flambe.is-a-geek.org>
gdbserver >= 7.2 comes with an optional library to use tracepoints, the
In Process Agent (IPA) library, libinproctrace.so.
Currently, we build gdbserver staticaly, but that breaks the build of
the IPA lib.
Add an option to biuld the IPA lib, but not if statically linking.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When saving a sample, use savedefconfig instead of copying
the full .config file.
This reduces the saved .config, and reduces clutter when it
is later upgraded.
Also use defconfig when retrieving a sample.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since I removed EXPERIMENTAL to most of gcc versions, the configuration
is now broken, as the required companion libraries versions are not
selectable, as they are still hidden behind EXPERIMENTAL.
Reported-by: Claudio Henrique Fortes Felix (chffelix on irc://irc.freenode.net/crosstool-ng)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
During application development it is desirable to enable malloc
debugging and LD_DEBUG support, but the extensive debug spew from
SUPPORT_LD_DEBUG_EARLY is only useful when working on
uClibc's ld.so.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
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>
Update Linux with the latest available revisions.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
[yann.morin.1998@free.fr: add a few other versions since released]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
Includes a patch to remove __builtin_expect test:
In eglibc-2.15, the build breaks in configure while testing
for the existance of __builtin_expect. It fails with newer
versions of gcc.
This patch is a modification of an upstream change in glibc
mainline (to be 2.16) to fix the following error:
[CFG ] checking for __builtin_expect... no
[ERROR] configure: error: support for __builtin_expect needed
http://sourceware.org/git/?p=glibc.git;a=commit;h=3857022a761ea7251f8e5c0e45d382ebc3e34cf9
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: coalesce both patches into a single changeset]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
sim was already disabled for CT_GDB_NATIVE.
Reviewed-by: Michael Hope
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@anciens.enib.fr: make it a config option]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add a toolchain-wide option to enable multilib.
This is currently a noop, and will be implemented
in subsequent patches for each impacted components.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.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>
Do not prompt for the type of floating-point support, if the
architecture did not explicitly stated that it did support it.
Reported-by: Morten Thunberg Svendsen <mts@doredevelopment.dk>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Changeset #149c33923f47 broke the architectures that do not
support the --with-float=X ./configure flag (in gcc). For example,
x86_64 does not support it.
Add a new blind config option that architectures can set to tell
they support floating point selection.
Reported-by: Morten Thunberg Svendsen <mts@doredevelopment.dk>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
First, 'SUPPORT' should be spelled 'SUPPORTS'.
Second, 'SUPPORT_XXX' really means 'supports --with-xxx', so rename the
affected options accordingly. Update the affected archs to match the new
namings.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@anciens.enib.fr: prompt rewording, as suggested by M. Hope]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
ARM compilers can be built for soft float (software only, floats in
core registers), hard float (uses floating point instructions, floats
in FPU registers), or the half-way house softfp (uses floating point
instructions, floats in core registers).
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some architectures support a mixed hard/soft floating point, where
the compiler emits hardware floating point instructions, but passes
the operands in core (aka integer) registers.
For example, ARM supports this mode (to come in the next changeset).
Add support for softfp cross compilers to the GCC and GLIBC
configuration. Needed for Ubuntu and other distros that are softfp.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
With the upcoming softfp support, the case..esac test would become
a bit convoluted if it were to test three different booleans.
Introduce a new blind string config option that defaults to the
selected floating point type used.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It's been a while now that crosstool-NG has been hosted on it's own
website, and not at my home. Change every reference to the old site
to the new one, everywhere is makes sense to.
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>
Add a new option to enable/disable the Python scripting in gdb.
Hide the option (ie. disable it) when statically linking the cross-gdb.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Allow the user to configure extra flags to pass to the host compiler
at build time. Applies to both C and C++.
Useful on Ubuntu to turn off the stack protector and fortify defaults
so the program stands a better chance of running on other distros.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: put the custom flags at the end]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
binutils 2.21 doesn't recognise the Cortex-M3 SVC instruction when
assembling with -mcpu=all. This was fixed by the 2.21.53 snapshot and
is needed to build RTOSs such as FreeRTOS.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
When CT_PARALLEL_JOBS is -1, set the number of parallel jobs to the
number of online CPUs + 1. Update documentation to match.
I find this useful when building in the cloud. You can use the same
.config file and have the build adapt to the number of processors
available. Limited testing shows that NCPUS+1 is faster than NCPUS+0
or NCPUS+2.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
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>
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>
Allows using either a tarball or a directory as the custom kernel
source location.
Signed-off-by: Vincent BENOIT <sinseman44@gmail.com>
[yann.morin.1998@anciens.enib.fr: fix space damage, detailed commit message]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Recently, all binutils versions have been renamed after a GPL compliance
issue was found and fixed in binutils;
http://sourceware.org/ml/binutils/2011-08/msg00198.html
Although legacy symlinks have been put in place, we should now use
the new, real version strings.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Recently, all binutils versions have been renamed after a GPL compliance
issue was found and fixed in binutils;
http://sourceware.org/ml/binutils/2011-08/msg00198.html
Old versions are no-longer available since the rename (eg. 2.19 has been
superseeded by 2.19.1, and only 2.19.1a was regenerated).
Remove now-missing versions.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Almost all versions have been renamed, but the gdb folks did not
setup legacy symlinks.
For more information, see this message:
http://sourceware.org/ml/gdb/2011-09/msg00002.html
Reported-by: ManuelStahl <manuel.stahl@iis.fraunhofer.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Finally fix typo introduced in #6eb0189d7225 and partially fixed in
#61ec8b08f98d...
Seems I'm fast at introducing trivial typoes, but bad at fixing them... :-(
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Having the crosstool-NG version in the .config helps in case we
want to reproduce the toolchain with the exact same version of
crosstool-NG.
This also reverts #bb73e7632b54.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Allows to choose if one wants to keep or not the syscalls that are provided with
newlib. It passes the --disable-newlib-supplied-syscalls or
--enable-newlib-supplied-syscalls to the configure script. If one chooses to
disable the builtin syscalls, he/she will have to write his/her own. This can
be usefull to port newlib to a new platform/board.
Signed-off-by: Kévin PETIT <kpet@free.fr>
Virtually all our targets do support stack unwinding. For some of
them, ./configure can't detect that, and the build fails later on.
So, default to force unwind, and let the user disable it if it
breaks in his/her case.
The previous changeset (f44286235a07) was empty, as spotted by Benoît.
Reported-by: Benoît THÉBAUDEAU <benoit.thebaudeau@advansee.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Simplify the way the custom tarball is handled:
- fake version="custom"
- at download, simply link the custom tarball to:
"linux-custom.${custom_extension}"
- at extract, the above allows to simply extract "linux-${LINUX_VERSION}"
where LINUX_VERISON is set to the fake version="custom"
Not that much convoluted, in fact... :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
No-one ever inquired about this feature. Due to the way it works, it is
rather unlikely that every user used a properly-formatted tarball, or a
properly structured directory as imput.
Beside, it is not really easy to maintain: I just spent one full day
remembering how it worked... Sigh... :-(
Just deprecate this, until next release, or until someone complains.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, the mirror can be used either:
- as a fallback in case upstream is unavailable (default behavior)
- as the preferred source for downloads
But the most common use-case seems to provide a truely-LAN mirror
to speed up downloads in big corpos', and/or provide a 'trusted'
source for the tarballs.
So, make the following changes;
- if a mirror is specified, always try that before trying upstream
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
svn is needed to download eglibc from the upstream repository.
In some situations, though, it can happen that:
- the developpers' machines do not have svn
- a LAN mirror has been set-up with pre-downloaded eglibc tarballs
In this case, it makes sense not to hard-depend on svn.
So, if svn is missing, just say so, and add a comment in the
menuconfig.
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This patch adds partial support for glibc locales.
For now, it only generates the appropriate locales when the host and the target
have the same endianness and uint32_t alignment.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch adds a common glibc/eglibc infrastructure to build and install the
libc locales.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
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>
Maintaining thos multi-line shell commands in a Makefile rule is
a real PITA.
Move the two affected rules (build_gen_choice_in and build_gen_menu_in
to a shell script.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
cvs is used to get newlib directly from its repository. Missing cvs
will only allow getting newlib from the released tarballs.
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>
Instead of getting eglibc over standard svn://svn.eglibc.org
Add an option that allows the user to get source from
http://www.eglibc.org/svn
This is useful if you are behind a firewall or proxy.
If you are behind a proxy, don't forget to configure
${HOME}/.subversion/servers
In the [global] section setup your proxy configuration.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@anciens.enib.fr: removed useless 'default n']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The patchset was obtained by dumping each changeset on the
upstream 0.9.32 branch since the release:
git log v0.9.32..origin/0.9.32 |sed -r -e '/^commit/!d; s/.* //;' |tac
and then creating a patch from each changeset.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Cross-gdb depends on expat and python. If either is missing, cross-gdb will
build successfully, but lacking some features.
Especially, if expat is missing, cross-gdb will be unable to parse the target
description, which may lead to runtime malfunctions and the following GDB
warning:
"Can not parse XML target description; XML support was disabled at compile time"
Hence, expat should be considered mandatory.
On the other hand, the features missing without python are not critical, so
python should not be considered mandatory.
This patch does the following:
- At configure time, warn the user if either expat or python is missing.
- In menuconfig, disable the static build options regarding cross-gdb if no
static version of expat is available, and disable cross-gdb if expat is
missing.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
[yann.morin.1998@anciens.enib.fr: add comment for impossible static cross-gdb]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
"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>
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 makes gdb benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes eglibc benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes binutils benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
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>
If check_for is able to find the required prog/inc/lib, allow it to
set an arbitrary variable to 'y'. This variable is then pushed down
to the kconfig definition.
For example:
has_or_abort prog=foobar kconfig=has_foobar
If foobar is available, it yields a kconfig variable defaulting to y:
config CONFIGURE_has_foobar
bool
default y
If foobar is missing, it yields a kconfig variable defaulting to n:
config CONFIGURE_has_foobar
bool
Thus it is possible to depends on that variabel to show/hide options:
config SOME_FEATURE
bool
prompt "Some feature"
depends on CONFIGURE_has_foobar
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
Now that kconfig can include a file multiple times, link the glibc/eglibc
common stuff to two .in.2 files.
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>
It can be quite confusing for a new-comer to find strange
version numbers for gdb, so hide the Linaro versions by
default.
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>
Re-organise the sub-menu so that:
- the kernels list comes first,
- followed by kernels generic options
- followed by kernels specific options
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Re-organise the sub-menu so that:
- the archs list comes first,
- followed by archs generic options
- followed by archs specific options
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In backend mode, setting the sysroot name is the
responsibility of the upper-layer build system.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Managing the shared version of the companion libraries
has become cumbersome.
Also, it will one day be possible to use the companion
libraries from the host distribution, and then we will
be able to easily use either shared or static libs.
As a side note, while working on the canadian-rework
series, it has become quite more complex to properly
handle shared companion libraries, as they need to be
built both for the build and gost systems. That's not
easy to handle. At all.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold can not build glibc/eglibc, force use of the BFD
linker during the toolchain build.
Reported-by: Bill Pringlemeir <bpringle@sympatico.ca>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc, so we have to
force using the BFD linker, ld.bfd.
Offer a blind option that affected components can select to
force use of the BFD linker during the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc. See this thread:
http://sourceware.org/ml/crossgcc/2011-04/msg00010.html
Reported-by: Bill Pringlemeir <bpringle@sympatico.ca>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The gold linker does currently support only a limited set of architectures:
- x86 (32- and 64-bit)
- ARM
Hide the gold option for other architectures.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add support for building SPARC targeted toolchain.
With this patch I have built a working sparc V8 (32 toolchain).
Testing shows that not all gcc versions works well:
4.4.1 OK (kernel builds and the final kernel can boot)
4.4.2 Not tested
4.4.3 Not tested
4.4.4 BAD (Kernel can build but fails during boot)
4.4.5 BAD (Kernel can build but fails during boot)
4.5.1 BAD (Build fails with a spill related ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664)
4.5.2 OK (kernel builds and boots)
I have successfully been using the 4.5.2 version for a few months.
This patch does not add support for the LEON variant.
That may come later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[yann.morin.1998@anciens.enib.fr: for 32-bit, default CT_TARGET_ARCH is OK]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
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>
In fact, it is only supported in a few legacy versions.
Keep LT available for all eglibc versions, although it might need
a similar safeguard...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
By default, recent versions of glibc and eglibc will build some
functions that take format strings (eg. printf, syslog...) with
run-time checks against some format string attacks. This is
called a fortified build.
Unfortunately, this fails somehow while building the instrumented
version of syslog, with some kind of circular dependency...
Disable fortified builds by default, and hide the enabling option
behind EXPERIMENTAL for daring users...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
I haven't noticed the usual experimental testers complain about eglibc
2.11 or 2.12 being unstable. So stop marking them as experimental.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
We make it an option, as not all combinations of architectures
vs. compiler vs. glibc/eglibc exhibit the issue. Mostly visible
on old glibc versions, it seems...
This is a missing part from the glibc/eglibc merger... :-/
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>
