crosstool-ng/config/target.in
Yann E. MORIN" 1906cf93f8 Add the full crosstool-NG sources to the new repository of its own.
You might just say: 'Yeah! crosstool-NG's got its own repo!".
Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup.
That means I'm putting backups in place in the afternoon.
That also means we've lost history... :-(
2007-02-24 11:00:05 +00:00

301 lines
8.7 KiB
Plaintext

# Target definition: architecture, optimisations, etc...
menu "Target options"
comment "General target options"
choice
bool
prompt "Target architecture:"
default ARCH_x86
config ARCH_ARM
bool
prompt "arm"
config ARCH_MIPS
bool
prompt "mips"
config ARCH_x86
bool
prompt "x86"
config ARCH_x86_64
bool
prompt "x86_64"
endchoice
choice
bool
prompt "Endianness:"
config ARCH_BE
bool
prompt "Big endian"
config ARCH_LE
bool
prompt "Little endian"
endchoice
comment "Target optimisations"
config ARCH_CPU
string
prompt "Emit assembly for CPU"
default ""
help
This specifies the name of the target ARM processor. GCC uses this name
to determine what kind of instructions it can emit when generating
assembly code.
Pick a value from the gcc manual for your choosen gcc version and your
target CPU.
Leave blank if you don't know, or if your target architecture does not
offer this option.
config ARCH_TUNE
string
prompt "Tune for CPU"
default ""
help
This option is very similar to the ARCH_CPU option (above), except
that instead of specifying the actual target processor type, and hence
restricting which instructions can be used, it specifies that GCC should
tune the performance of the code as if the target were of the type
specified in this option, but still choosing the instructions that it
will generate based on the cpu specified by the ARCH_CPU option
(above), or a (command-line) -mcpu= option.
Pick a value from the gcc manual for your choosen gcc version and your
target CPU.
Leave blank if you don't know, or if your target architecture does not
offer this option.
config ARCH_ARCH
string
prompt "Achitecture level"
default ""
help
GCC uses this name to determine what kind of instructions it can emit
when generating assembly code. This option can be used in conjunction
with or instead of the ARCH_CPU option (above), or a (command-line)
-mcpu= option.
Pick a value from the gcc manual for your choosen gcc version and your
target CPU.
Leave blank if you don't know, or if your target architecture does not
offer this option.
config ARCH_FPU
string
prompt "Use FPU"
default ""
help
On some targets (eg. ARM), you can specify the kind of FPU to emit
code for.
See below wether to actually emit FP opcodes, or to emulate them.
Pick a value from the gcc manual for your choosen gcc version and your
target CPU.
Leave blank if you don't know, or if your target architecture does not
offer this option.
choice
bool
prompt "Floating point:"
config ARCH_FLOAT_HW
bool
prompt "hardware (FPU)"
help
Emit hardware floating point opcodes.
If you've got a processor with a FPU, then you want that.
If your hardware has no FPU, you still can use HW floating point, but
need to compile support for FPU emulation in your kernel. Needless to
say that emulating the FPU is /slooowwwww/...
One situation you'd want HW floating point without a FPU is if you get
binary blobs from different vendors that are compiling this way and
can't (don't wan't to) change.
config ARCH_FLOAT_SW
bool
prompt "software"
help
Do not emit any hardware floating point opcode.
If your processor has no FPU, then you most probably want this, as it
is faster than emulating the FPU in the kernel.
endchoice
config ARCH_FLOAT_SW_LIBFLOAT
bool
prompt "Use libfloat"
default n
depends on ARCH_FLOAT_SW
help
For those targets upporting it, you can use libfloat for the software
floating point emulation.
Note that some versions of gcc have support code that supersedes libfloat,
while others don't. Known version of gcc that don't have support code are
versions prior to 3.0, and version above 4.0.
You should check gcc before deciding to use libfloat.
config TARGET_CFLAGS
string
prompt "Default target CFLAGS"
default ""
help
Used to add specific options when compiling libraries of the toolchain,
that will run on the target (eg. libc.so).
Note that the options above for CPU, tune, arch and FPU will be
automaticaly used. You don't need to specify them here.
Leave blank if you don't know better.
comment "Toolchain options"
config USE_SYSROOT
bool
prompt "Use sysroot'ed toolchain"
default y
help
Use the 'shinny new' sysroot feature of gcc: libraries split between
prefix/target/sys-root/lib and prefix/target/sys-root/usr/lib
You definitely want to say 'Y' here. Yes you do. I know you do. Say 'Y'.
config SHARED_LIBS
bool
prompt "Build shared libraries"
default y
help
Say 'y' here, unless you don't want shared libraries.
You might not want shared librries if you're building for a target that
don't support it (maybe some nommu targets, for example, or bare metal).
config TARGET_MULTILIB
bool
# prompt "Enable 'multilib' support (EXPERIMENTAL)"
default n
help
Enable the so-called 'multilib' support.
With the same toolchain, and on some architectures, you will be able to
build big and little endian binaries, soft- and hard-float, etc...
See the gcc configure manual at http://gcc.gnu.org/install/configure.html
to see what multilib your target supports.
It's preferable for now to build two (or more) toolchains, one for each
configuration you need to support (eg. one for thumb and one for ARM,
etc...). You can use the vendor string to diferentiate those toolchains.
config TARGET_VENDOR
string
prompt "Vendor string"
default "unknown"
help
Vendor part of the machine triplet.
A triplet is of the form arch-vendor-kernel-system.
You can set the second part, vendor, to whatever you see fit.
Use a single word, or use underscores "_" to separate words.
Keep the default (unkown) if you don't know better.
config TARGET_ALIAS
string
prompt "Target alias"
default ""
help
Normaly, you'd call your toolchain component (especially gcc) by
prefixing the target triplet followed by a dash and the component name
(eg. armeb-unknown-linux-uclibc-gcc).
You can enter a shortcut here. This string will be used to create
symbolic links to the toolchain tools (eg. if you enter "foo-bar" here,
then gcc for your toolchain will also be available as "foo-bar-gcc" along
with the original name).
You shouldn't need to enter anything here, unless you plan to manually
call the tools (autotools-based ./configure will use the standard name).
config ARCH
string
default "arm" if ARCH_ARM
default "mips" if ARCH_MIPS
default "x86" if ARCH_x86
default "x86_64" if ARCH_x86_64
config BUILD
string
prompt "Build system triplet"
default ""
help
Canonical name of the machine building the toolchain.
You should leave empty, unless you really now what you're doing.
config CC_NATIVE
string
prompt "Native gcc"
default "gcc"
help
The native C compiler.
You can set this to an alternative compiler if you have more than one
installed (eg. gcc is gcc-4.1.1 and you want to use gcc-3.4.6).
You can leave this empty as well, in which case gcc will be used.
config CANADIAN
bool
prompt "Canadian build (EXPERIMENTAL)"
default n
help
A canadian build allows to build a compiler on a first machine
(build system), that will run on second machine (host system),
targetting a third machine (target system).
An example where you'd want a candian cross-compiler is to create
a native compiler for your target. In this case host and target
are the same.
config HOST
string
prompt "Host system triplet"
default ""
depends on CANADIAN
help
Canonical name of the machine serving as host.
config HOST_CC
string
prompt "Host system compiler"
default "${CT_HOST}-"
depends on CANADIAN
help
C compiler targeting the host system.
If HOST_CC ends with a dash (-), then it is considered to be the
prefix to gcc (eg. x86-pc-linuc-gnu-).
If it is empty, it is formed by appending '-gcc' to HOST.
Else it is considered to be the complete name of the compiler, with
full path, or without path (provided that it can be found in PATH).
endmenu