This patch fixes the download of the avr32 headers in crosstool-ng by
fetching them directly from Atmel's web site instead of the now-broken URL
given by the original author of the avr32-header-fetching modification,
who fetched them from a copy on his own, now-defunct server.
It also adds the necessary logic to extract from a zip file, as that is
how the headers are packaged.
To configure it for avr32 after launching ct-ng menuconfig in an empty
directory:
Paths and misc options ->
Shell to use as CONFIG_SHELL = sh
Target options ->
Target Architecture = avr32
Toolchain options ->
Tuple's alias = avr32
Binary utilities ->
binutils version = 2.18a
C compiler
gcc version = 4.2.2
C-library
newlib version = 1.17.0
Enable IOs on long long = yes
Enable IOs on floats and doubles = yes
Disable the syscalls supplied with newlib = yes
CONFIG_SHELL is necessary to get round the "fragment: command not
found" bug when binutils-2.18 is configured using bash.
Prepared against crosstool-ng mercurial trunk on 31 March 2012.
Signed-off-by: Martin Guy <martinwguy@gmail.com>
[yann.morin.1998@free.fr: update bundles sample accordingly]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <CAL4-wQrg_NQ7jm-NCADqeyQr9twyhtx42OUGNThP6gWeqZc=kw@mail.gmail.com>
Patchwork-Id: 232612
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Rafael C <groups.r2@gmail.com>
Cc: Jérôme BARDON <bardon.pro@gmail.com>
Cc: Daniel Price <daniel.price@gmail.com>
Reported-by: Rafael C <groups.r2@gmail.com>
Reported-by: Jérôme BARDON <bardon.pro@gmail.com>
Reported-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: use a conditional approach, also suggested by Daniel]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
There's no point in not supporting XML in the cross-gdb.
I mean, come on... ;-)
It's still the responsibility of the user to have the necessary
devel expat packages installed for his/her distro.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
For the native-gdb (ie on the target), we unconditionally
need to build expat.
Make it a backend, it makes a litle bit cleaner code.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
It should be used only to decide whether we need to download/extract
ncurses, not wheter we should build it or not.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Rename those three variables to properly reflect their purpose: decide
whether we need to download/extract gdb/libexpat/libncurses, not whether
we need to build them or not.
This is only a rename for now, subsequent changes will further
fix this mess.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The menu system provides an option to allow a user to request newlib
version 2.0.0. newlib-2.0.0, however, is not available at the download
location currently being used. It is, however, available (as are other
supported versions of newlib) at an alternate location.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Message-Id: <75ab5151c7f5dc9086e3.1362334313@suse64>
Patchwork-Id: 224561
In case we only download or extract the sources, do not fail while
finishing the toolchain: the test-suite directory may not exist, so
we can't chmod it.
Also, use safer constructs that won't trigger the 'set -e' in case of
failure (eg.: "[ ... ] && ..." is not safe in case the test fails).
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>
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>
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>
The one was missing from the list.
It is very improbable that we ever need it, as elf2flt does no release,
and we always get it from CVS head. But for the sake of consistency, we
just add it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
While most components have their version in the .in file, some
have it in the .in.2 (eg. elf2flt).
Currently, to handle this case, we indiscriminately munge both files,
but this is wrong: in the elf2flt case, if we add a binutils version,
we do not want it to be added to elf2flt, and conversely.
So, for each tool, we need to explicitly know what file to munge.
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>
Since unrecognised ./configure flags are simply ignored,
we can always pass --enable-obsolete-rpc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since we've had the debug shell feature, fd #7 is now used to
redirect stderr, while it was previously unused.
Use fd #9 to redirect stdout.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
xldd uses sed and grep as detected by ./configure. This works well if is
used on the machine that build the toolchain.
But if the user moves the toolchain to another machine where sed and grep
are not in the same directory (eg. /bin/sed vs. /usr/bin/sed), then xldd
will stop functionning.
Fix that by using ${SED} and ${GREP} if they are set in the environment.
Reported-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
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
Properly catch resuming the build when continuing past the
failed command.
The 'case ;;&' construct is a bash4ism. Get rid of it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The current mechanism to check if static linking is possible, and the mesage
displayed on failure, can be puzzling to the unsuspecting user.
Also, the current implementation is not using the existing infrastructure,
and is thus difficult to enhance with new tests.
So, switch to using the standard CT_DoExecLog infra, and use four tests to
check for the host compiler:
- check we can run it
- check it can build a trivial program
- check it can statically link that program
- check if it statically link with libstdc++
That should cover most of the problems. Hopefully.
(At the same time, fix a typo in a comment)
Signed-off-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: split original patch for self-contained changes]
[yann.morin.1998@free.fr: use steps to better see gcc's output]
[yann.morin.1998@free.fr: commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <163f86b5216fc08c672a.1353459722@nipigon.dssd.com>
Patchwork-Id: 200536
Signed-off-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: split original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <163f86b5216fc08c672a.1353459722@nipigon.dssd.com>
Patchwork-Id: 200536
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
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
Use the same method as companion tools for providing generic and
extendable companion libs.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <515c5c4635d99ebe4877.1353074410@macbook-smorlat.local>
Patchwork-Id: 199613
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
The extra CFLAGS override the product defaults, causing the product to
be built without optimisation or debug. Be explicit and add these in.
Reported-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Message-Id: <CANLjY-=3Gbio6nzUPhhevDHV7cUN=6Vigooe9nSf-RnGCqnjog@mail.gmail.com>
Patchwork-Id: 198808
While eglibc-2.16 recommends to use TI-RPC instead of the old sunrpc, the
old one can be included using a configure option. Since the user can still
use TI-RPC to override the libc implementation, we enable rpc unconditionally.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Message-Id: <20121102140404.GA7707@sig21.net>
Patchwork-Id: 196564
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>
CT_DEBUG_INTERACTIVE is disabled when stdin, stdout or
stderr are redirected, but the check is only done at
the start of the build and doesn't catch when individual
build commands use redirection. When stdin is redirected
it will cause the debug shell to exit immediately, causing
and endless loop. Thus, save the stdin/our/err file handles
and restore them before invoking the debug shell.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Message-Id: <20121030102225.GA8303@sig21.net>
Patchwork-Id: 195409