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
This makes the patch name show up on the command line
logged by CT_DoExecLog so it's easier to see
what is going on. The -i for patch is specified
by Posix and supported by GNU patch and busybox patch.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
[yann.morin.1998@free.fr: remove now-useless debug message]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <20121030103620.GB8303@sig21.net>
Patchwork-Id: 195418
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>
That's legacy code that was usefull when ncurses was installed
in the sysroot. Still it's not longer the case (it's installed
in a special dedicated directory), we can remove that piece of
code.
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
Since we added the debug-shell feature, CT_DoExecLog no longer
returns the error code of the command, but always return 0.
This breaks the download mechanism, which relies on CT_DoExecLog
to fail _on_purpose_ to detect that the ressource was not found
at the specified URL.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
So we get caught by the trap-handler and
have a chance to run the debug-shell.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Johannes Stezenbach <js@sig21.net>
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
Avoid error when commands in scripts/crosstool-NG.sh fail
before CT_BUILD_DIR is set.
So we need to remove the backtrace marker of a potential previous
build. Previously, it was implicitly removed because we did remove
the directory it was in, which is no longer the case.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
[yann.morin.1998@free.fr: remove backtrace marker on start of build]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <20121015094615.GA18673@sig21.net>
Patchwork-Id: 191498
It's been a long time the default work-dir changed its name
from 'target' to '.build'.
Change the left-over.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Currently, extract and patch are skipped as thus:
- using a custom directory of pre-installed headers
- a correctly named directory already exists
Otherwise, extract and patch are done.
The current second condition is wrong, because it allows the following
sequence to happen:
- a non-custom kernel is used
- a previous build only partially extracted the non-custom sources
- that p[revious build broke during extraction (eg. incomplete tarball...)
- a subsequent build will find a properly named directory, and will
thus skip extract and patch, which is wrong
Fix that by following the conditions in this table:
Type | Extract | Patch
----------------------+---------+-------
Pre-installed headers | N | N
custom directory | N | N
custom tarball | Y | N
mainstream tarball | Y | Y
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: David Holsgrove <david.holsgrove@xilinx.com>
Config options remain the same as before, just generalised to be used by other
components also.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
[yann.morin.1998@free.fr: fix indentation, fix comment]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <50674fe47431174aab80.1349931193@localhost.localdomain>
PatchWork-Id: 190786
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
Previous import from patchwork missed one hunk (in cset #d8feb93b3e49)
Apply it now.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Patchwork-Id: 189053
Attempting to ${CT_TARGET}-gcc -print-multi-lib will fail
In do_cc_core_backend, for the final compiler in a canadian cross
baremetal, warn that multi-libs cannot be determined
In do_cc_backend, for either final compiler for a canadian cross,
warn that multi-libs cannot be determined
(Plus fixed CT_PREFIX_DIR in do_cc_backend to be ${prefix})
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Message-Id: <CAM=EW8aQDoNx-CkJHjXBoDP4iTDJ8z5hh3=KhO5UTU6rp3Pj=w@mail.gmail.com>
Patchwork-Id: 189053
--with-expat=yes is unconditionally passed to the gdb configure
stage, instead of respecting the ${do_expat} decision.
Disable if not needed. Prevents error building canadian cross;
configure: error: expat is missing or unusable
Where configure stage fails to find expat on the host compiler.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <4c4410a2a8aab24a29c5.1349244128@localhost.localdomain>
PatchWork-Id: 188711
GCC requires m68k arch tuples to be *-*-uclinux-* to support Linux on
no-mmu m68k (ColdFire) cpus.
Blackfin arch tuple must be *-*-linux-uclibc for FD_PIC_ELF toolchains,
so we cannot just switch to uclinux for no-mmu Linux toolchains.
Signed-off-by: "Esben Haabendal" <esben@haabendal.dk>
Message-Id: <876271s1ee.fsf@arh128.prevas.dk>
PatchWork-Id: 186976
If either LIBRARY_PATH or LPATH is set, even to the empty string,
the gcc build breaks.
Fix that by bailing-out rather than re-setting.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
These environment variables set search path for gcc at link time, which can break the build.
Signed-off-by: Erik Inge Bolsø <knan-ct@anduin.net>
Message-Id: <alpine.BSF.2.00.1205130131550.21551@anduin.net>
PatchWork-Id: 186872
build fails to symlink to custom kernel dir when the build is not the first time
because of 'ln -s' without '-f' option.
Signed-off-by: "Jang, Bongseo" <graycells@gmail.com>
Message-ID: <543e2981f2b723ecd850.1348370892@localhost.localdomain>
PatchWork-ID: 186178
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>
That comes from way back when nothing would work as expected, and I would
easily get heated as soon as anything would break. Sigh, those were the
old days.
Apologies.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
For expat, duma, and strace, use the generic url and 302 to the mirror
instead of trying to download a file from a downed mirror and
failing.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <b69ebeb72fef93c04c84.1345364051@flambe.is-a-geek.org>
Whatever the threading model (NPTL, LT...), we build the same
core pass-1 compiler, so there is no need to have a case-esac
construct.
Remove now mis-leading and incorect comment.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
New binutils (circa 2.2x?) append 'program interpreter' to the
(NEEDED) line for the dynamic linker, which breaks our current
pattern.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Both core pass-1 and -2 compilers are unconditionally built,
so we no longer require a condition variable.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Up until now, all conditions requiring a core pass-1 was when the
threading implementation used was NPTL. So we only built the core
pass-1 when NPTL was used.
Now, things have changed (what? when? Dunno...), and some bare-metal
canadian toolchains fail to build if a core pass-1 is not present.
OTOH, a core pass-1, although not needed for non-NPTL builds, does
no harm at all if it is present.
So, unconditionally build a core pass-1 (but still pass conditional
options to the core backend).
Reported-by: Per Arnold Blaasmo <Per-Arnold.Blaasmo@atmel.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Because we now patch configure.in and configure, the Makefile quicks
in a re-build rule as the source files are now more recent than the
bundled generated files, and that fails because the m4 directory
is missing, although on some systems where aclocal is not installed,
the re-build rule does nothing (except a warning).
Always create tht directory.
Reported-by: Per Arnold Blaasmo <per-arnold.blaasmo@atmel.com>
[Also thanks to Thomas De Schampheleire <patrickdepinguin@gmail.com>
for some digging works on this issue]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since we use defconfigs to save the samples, listing all the
samples can no longer be done by passing all the sample names
at one to the script; we need to pass them one-by-one after
we expand the sample's defconfig ibnto a complete .config.
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
Now that we are using defconfig files, the samples do not contain
the full configuration, so we can not simply parse them to show
their content.
Instead, we must fake recalling a sample, and parse the generated
.config file.
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>
POSIX 1003.1-2008 does not say whether "set -e" should catch a sub-shell
that exits with !0 (it has a list of conditions to catch, but no list of
conditions not to catch, and this situation is not listed).
bash-3 does not catch such a failure, but bash-4 does. That why, on my
Squeeze system I did not see the issue, while Thomas did on is Lenny chroot.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
Autoconf can determine that the correct install command includes flags,
e.g., "/usr/bin/install -c". When using this as a command, we can't
enclose the value in double-quotes, as that makes some shells use the
whole expression as a filename:
# this is the value returned by autoconf and stored in CT_install
$ ins="/usr/bin/install -c"
# if we call it with quotes, the command is not found
$ "${ins}"
bash: /usr/bin/install -c: No such file or directory
# removing the quotes lets it work as expected
$ ${ins}
/usr/bin/install: missing file operand
Try `/usr/bin/install --help' for more information.
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
When updating a sample configuration with a comment, a dot '.'
in the new comment keeps the previous comment.
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>
Bizarrely enough, the core gcc are not enough to be able to build a
canadian cross, and a real, full cross compiler is required so that
the canadian cross can be properly built... WTF?!? Sigh...
Add a build-frontend, as was done for the binutils and the complibs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Do for the final step the same as for the core step: compute the list
of selected langauages from the frontend, not in the backend.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
As the core backend can be used to also build the bare-metal compiler,
we have to tel it what languages to build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add a function that prepares the language configure option.
It is needed in at least two places, some commonalisation is needed. ;-)
Unfortunately, it is no longer possible to print warnings about experimental
languages any more. Anyway, the experimental status is clearly indicated
in the menuconfig. so it should not be a surprise if the build breaks. :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It's easier to have as much as possible stuff in the same place to
ease backup/restore, and make things easier to follow.
Move the host companion libraries install dir as a sub-dir of the
build-tools install dir (but not directly in it, it would break
for canadian or cross-native).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
A few noop fix-ups:
- fix the comments in core pass-1
- commonalise settings that can be
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In canadian-cross, we need the companion libraries running on the
build machine, to be able to build the two core gcc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In canadian-cross, we need binutils running on the build machine to be
able to build the target C library.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move the actual complibs codes to backend functions that builds the
required combo of build/host/target as requested by a frontend.
This split is currently a no-op, but is required for the upcoming
canadian-cross rework, where we'll be needing to build the complibs
twice, one for build/build, and one for build/host.
This applies to the six companion libraries:
- GMP
- MPFR
- PPL
- Cloog/PPL
- MPC
- libelf
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move the actual binutils code to a backend function that builds the
required combo of build/host/target as requested by a frontend.
This split is currently a no-op, but is required for the upcoming
canadian-cross rework, where we'll be needing to build two binutils,
one for build/build/target, and one for build/host/target.
This applies to the three binutils:
- GNU binutils
- elf2flt
- sstrip
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The core compilers are used to build the C library, so they
should always run on the build machine, not on the host.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There really is no good reason to install the core compilers in their
own places, one for each pass. We can install them with the other
build tools.
Also, this implies that:
- there are fewer directories to save/restore
- there are fewer symlinks to create for binutils
- the PATH is shorter
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a canadian-cross, the binutils are not executable on
the build machine, so there is no point in installing the symlinks
in the gcc static/shared install dirs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
strace upstream location has slightly changed.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since anciens.enib.fr has been dead for two months now, without any
hope of recovery, update my e-mail to point to @free.fr instead.
Reported-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The build dir are created depending on the host (host for that specific
backend, not host for the toolchain). Only the frontends know what host
this is, so only the frontends can create non-ambiguous dirs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
A lot of places are currently doing:
mkdir -p foo/bar
cd foo/bar
Or even:
mkdir -p foo/bar
pushd foo/bar
[...]
popd
Provide both wrapper to ease doing this.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The only user of the static core compiler in pass-1 was the newlib
C library. Now that it is build in a later step, we do no longer
need to build a static core compiler in pass-1.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, newlib is built in the start_file step, which is wrong, but was
needed when the baremetal integration was... well, 'unfinished'.
Now that we build the baremetal compiler from the final cc step, and a
proper core gcc in pass-1 and pass-2, we can move the newlib build to the
step do_libc, where it belongs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case we build a baremetal compiler, use the standard passes:
- core_cc is used to build the C library;
- as such, it is meant to run on build, not host;
- the final compiler is meant to run on host;
As the current final compiler step can not build a baremetal compiler,
call the core backend from the final step.
NB: Currently, newlib is built during the start_files pass, so we have
to have a core compiler by then... Once we can build the baremetal
compiler from the final cc step, then we can move the newlib build to
the proper step, and then get rid of the core pass-1 static compiler...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, we issue the bare-metal compiler from the pass_1 & pass_2
core compilers, because the final gcc breaks while doing so.
This implies we have to build some libces during the start_files step,
instead of the standard libc step. This is the case for newlib.
By adding a backend/frontend infra to the final gcc, we can abstract
what backend to call: the standard backend for non-bare-metal gcc,
and the core backend for bare-metal.
This patch is just an no-op, it just adds the final backend and
frontend without changing the way bare-metal is built, to come in a
subsequent patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As the core backend is used to generate the bare-metal compiler,
we need to pass it the host CFLAGS.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Tell the core compiler what host it should run on (instead of
hard-coding runing on CT_HOST).
No functional change so far, switching between CT_HOST and CT_BUILD
will come in a following patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, the discrimination on the core compilers prefixes depends on
the type of core compiler to build.
This is not correct, and the caller of the core backend should specify
the prefix.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case of canadian-cross, the companion libraries are not the same for
the core cc (they run on 'build') as they are for the final cc (they run
on 'host').
Prepare for this differentiation (coming later), while retaining the
current behavior (to use the same compblibs).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Rename the core backend function to do_cc_core_backend, to
make it explicit it is a backend.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The core backend is going to have more parameters in the upcoming
patches, so it will be a bit complex to handle.
Introduce an array-variable that is filled by the different code-paths
with the required values.
This makes the code easier to read and maintain.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The current construct consumes the parameters while we parse them.
Change this to a construct that does not consume the parameters.
This has no impact on gcc, but is done for homogeneity with other
components (eg. glibc).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, there are two constructs used to parse arguments in
glibc backends, one that consumes args as they are parsed, and
one that does not.
Always use the construct that does not eat args as they are parsed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It seems sourceforge changed yet again the way to download files.
This time, no longer use their 'mesh' thingy, and hard-code the
server to use in the URL... Sigh... :-(
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
