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).
Add a new command line option, "-r", which allows the user to specify
an alternate sysroot location to copy libraries from. This is useful
when using the toolchain in combination with a separate root filesystem,
or when working with multiple different root filesystems.
Signed-off-by: Nate Case <ncase@xes-inc.com>
sstrip is now alone in its 'tools' menu, and we will probably never gain
any other 'tool'. Besides, sstrip is just strip, but a little bit more
agressive, so it deserves going to the 'binary utilities' menu.
The native 'tic' will _always_ be run on the build
machine, so no need to handle canadian/native/...
Reported by: Trevor Woerner
http://sourceware.org/ml/crossgcc/2010-03/msg00055.html
(transplanted from 26e89d367ea11660fd3a0bf0bcad8763e4fa21cf)
ltrace uses i386 and x86_64, whereas crosstool-NG use x86 for both cases.
Fix that by detecting what bitness we're building for, and pass appropriate
i386 or x86_64 to ltrace's configure.
The companion libraries on the target are required only for internal use by
binutils and gdb. The user should not have to know about this, so hide the
option.
On some systems (eg. *BSD and Darwin), date does not support nanoseconds
(%N) precision. Instead of printing '%N' in this case, it just prints 'N'.
Fix the sed expression to handle this case.
Add a git wrapper to retrieve components from their git tree.
Add a git wrapper to create a working copy (in our tarballs dir).
Recognise git trees when searching for local copies.
We can not rely on the user-provided version string (be it via the
choice, or manually entered), so fallback to reading version.h,
which is both reliable and always present.
It's now been a while that glibc switched to git from cvs.
Get rid of cvs to download glibc; this will make for a good
cleanup before we add git support! :-)
It's broken anyway. Eg.:
- user is already niced at 10
- user configures to renice at 5
- breaks because user is not allowed to 'boost' his/her nice value
Bette let the user handle the renice with:
nice -XX ct-ng 'action'
Signed-off-by: Remy Bohmer <linux@bohmer.net>
[yann.morin.1998@anciens.enib.fr: use defaults for CT_TARGET_ARCH]
Signed-off-by: "Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
