For uClibc, the name of the Blackfin architecture is 'bfin'. Actually,
the naming of the architecture is quite messy: for toolchain tuples
and uClibc, it's bfin, but for the kernel, it's blackfin. We've
arbitraly choosen to name it "blackfin" in Crosstool-NG.
Add Blackfin-related uClibc patch to fix a build failure related to
fork() being used in unistd/daemon.c.
Yann E. MORIN:
Apply the patch to the kernel/linux build script to use 'linux'
in the noMMU tuples. See:
http://sourceware.org/ml/crossgcc/2010-04/msg00010.html
Saving and restoring the steps requires saving/restoring multiple
directories. Depending on the configuration, some may not exist.
Add a wrapper that checks before creating/extracting the tarballs.
Disable unaligned access at least for mcpu32, m68010 and m68020.
These processors certainly do not like unaligned accesses.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
When building for bare-metal the core-gcc compiler is delivered
as final compiler, so the version info and bugurl is useful
in the core compiler as well.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
When building a baremetal cross compiler I want to be able to select
the elf format and not be forced to build the elf2flt package.
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[Yann E. MORIN: tweak the commit message]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Not all target tuples consist of an VENDOR, KERNEL and SYSTEM part, build up the
tuple in such a way to no extra or trailing dashes are added to CT_TARGET
Signed-off-by: Bart vdr Meulen <bartvdrmeulen@gmail.com>
In some exotic case the autoreconf step of mpfr is not executed (correctly)
leaving an incorrect version number for libtool in the configure script.
After extracting the sources files, force autoreconf to be executed.
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
[Yann E. MORIN: mark it EXPERIMENTAL]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
- don't list samples in the main help screen
- improve the samples listing in list-samples
- don't document the 'config' action, it's long dead
- document the 'V' environment variable
- improve on START, STOP and PREFIX environment variables
- add PREFIX and V to autocomplete
- advertise auto-complete at install time
Hide the prompts for some behavioral options, for which the upper-layer build
system is responsible for:
- parallel jobs and maximum load
- use pipes
- use custom shell
When crosstool-NG is used as a backend, it is the responsibility of the
upper-layer build-system to properly set paths, so we just hide the
prompts in this case.
Curently, populate will iterate over all ELF (shared objects|executables)
to look for missing NEEDED DSOs, adding to the list at every iterations
of the search loop.
Instead of looking again at previously handled ELF files, recursively
resolve every ELf files.
Also, in case there are a whole lot of files (more than the shell can
accept as arguments list, or creating a command line longer than the
shell can cope with), use a temporary file with the list of files
to search for missing dependencies.
- it's a POSIX compliant shell script: drop bash, use /bin/sh
- fix help text
- use an absolute path for sysroot
- replace "echo" with "printf"
- replace "stat -c '%i'" with "ls -1id"
- replace "pushd / popd" with "cd / cd -"
- remove superfluous break
- bail out if required lib not found, except if forced
If a list-file is used, then each library in the file will be handled
twice (not a real issue, as the second iteration will find the library
already present, just avoid doing the job twice).
This fixes two problems:
- the sysroot might be in a sub-directory (think SYSROOT_DIR_PREFIX)
- it is not needed to have the target tuple to properly detect the sysroot
and the required tools
As a side effect, this script is now no longer dependent on the target
tuple, and in the future, we might be able to share it across many
toolchains (when/if we can install all of them in the same place).
