config/target.in
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sat Feb 24 11:00:05 2007 +0000 (2007-02-24)
changeset 1 eeea35fbf182
child 35 2dce00870893
permissions -rw-r--r--
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... :-(
yann@1
     1
# Target definition: architecture, optimisations, etc...
yann@1
     2
yann@1
     3
menu "Target options"
yann@1
     4
yann@1
     5
comment "General target options"
yann@1
     6
yann@1
     7
choice
yann@1
     8
    bool
yann@1
     9
    prompt "Target architecture:"
yann@1
    10
    default ARCH_x86
yann@1
    11
yann@1
    12
config ARCH_ARM
yann@1
    13
    bool
yann@1
    14
    prompt "arm"
yann@1
    15
yann@1
    16
config ARCH_MIPS
yann@1
    17
    bool
yann@1
    18
    prompt "mips"
yann@1
    19
yann@1
    20
config ARCH_x86
yann@1
    21
    bool
yann@1
    22
    prompt "x86"
yann@1
    23
yann@1
    24
config ARCH_x86_64
yann@1
    25
    bool
yann@1
    26
    prompt "x86_64"
yann@1
    27
yann@1
    28
endchoice
yann@1
    29
yann@1
    30
choice
yann@1
    31
    bool
yann@1
    32
    prompt "Endianness:"
yann@1
    33
yann@1
    34
config ARCH_BE
yann@1
    35
    bool
yann@1
    36
    prompt "Big endian"
yann@1
    37
yann@1
    38
config ARCH_LE
yann@1
    39
    bool
yann@1
    40
    prompt "Little endian"
yann@1
    41
yann@1
    42
endchoice
yann@1
    43
yann@1
    44
comment "Target optimisations"
yann@1
    45
yann@1
    46
config ARCH_CPU
yann@1
    47
    string
yann@1
    48
    prompt "Emit assembly for CPU"
yann@1
    49
    default ""
yann@1
    50
    help
yann@1
    51
      This specifies the name of the target ARM processor. GCC uses this name
yann@1
    52
      to determine what kind of instructions it can emit when generating
yann@1
    53
      assembly code.
yann@1
    54
      
yann@1
    55
      Pick a value from the gcc manual for your choosen gcc version and your
yann@1
    56
      target CPU.
yann@1
    57
      
yann@1
    58
      Leave blank if you don't know, or if your target architecture does not
yann@1
    59
      offer this option.
yann@1
    60
yann@1
    61
config ARCH_TUNE
yann@1
    62
    string
yann@1
    63
    prompt "Tune for CPU"
yann@1
    64
    default ""
yann@1
    65
    help
yann@1
    66
      This option is very similar to the ARCH_CPU option (above), except
yann@1
    67
      that instead of specifying the actual target processor type, and hence
yann@1
    68
      restricting which instructions can be used, it specifies that GCC should
yann@1
    69
      tune the performance of the code as if the target were of the type
yann@1
    70
      specified in this option, but still choosing the instructions that it
yann@1
    71
      will generate based on the cpu specified by the ARCH_CPU option
yann@1
    72
      (above), or a (command-line) -mcpu= option.
yann@1
    73
      
yann@1
    74
      Pick a value from the gcc manual for your choosen gcc version and your
yann@1
    75
      target CPU.
yann@1
    76
      
yann@1
    77
      Leave blank if you don't know, or if your target architecture does not
yann@1
    78
      offer this option.
yann@1
    79
yann@1
    80
config ARCH_ARCH
yann@1
    81
    string
yann@1
    82
    prompt "Achitecture level"
yann@1
    83
    default ""
yann@1
    84
    help
yann@1
    85
      GCC uses this name to determine what kind of instructions it can emit
yann@1
    86
      when generating assembly code. This option can be used in conjunction
yann@1
    87
      with or instead of the ARCH_CPU option (above), or a (command-line)
yann@1
    88
      -mcpu= option.
yann@1
    89
      
yann@1
    90
      Pick a value from the gcc manual for your choosen gcc version and your
yann@1
    91
      target CPU.
yann@1
    92
      
yann@1
    93
      Leave blank if you don't know, or if your target architecture does not
yann@1
    94
      offer this option.
yann@1
    95
yann@1
    96
config ARCH_FPU
yann@1
    97
    string
yann@1
    98
    prompt "Use FPU"
yann@1
    99
    default ""
yann@1
   100
    help
yann@1
   101
      On some targets (eg. ARM), you can specify the kind of FPU to emit
yann@1
   102
      code for.
yann@1
   103
      
yann@1
   104
      See below wether to actually emit FP opcodes, or to emulate them.
yann@1
   105
      
yann@1
   106
      Pick a value from the gcc manual for your choosen gcc version and your
yann@1
   107
      target CPU.
yann@1
   108
      
yann@1
   109
      Leave blank if you don't know, or if your target architecture does not
yann@1
   110
      offer this option.
yann@1
   111
yann@1
   112
choice
yann@1
   113
    bool
yann@1
   114
    prompt "Floating point:"
yann@1
   115
yann@1
   116
config ARCH_FLOAT_HW
yann@1
   117
    bool
yann@1
   118
    prompt "hardware (FPU)"
yann@1
   119
    help
yann@1
   120
      Emit hardware floating point opcodes.
yann@1
   121
      
yann@1
   122
      If you've got a processor with a FPU, then you want that.
yann@1
   123
      If your hardware has no FPU, you still can use HW floating point, but
yann@1
   124
      need to compile support for FPU emulation in your kernel. Needless to
yann@1
   125
      say that emulating the FPU is /slooowwwww/...
yann@1
   126
      
yann@1
   127
      One situation you'd want HW floating point without a FPU is if you get
yann@1
   128
      binary blobs from different vendors that are compiling this way and
yann@1
   129
      can't (don't wan't to) change.
yann@1
   130
yann@1
   131
config ARCH_FLOAT_SW
yann@1
   132
    bool
yann@1
   133
    prompt "software"
yann@1
   134
    help
yann@1
   135
      Do not emit any hardware floating point opcode.
yann@1
   136
      
yann@1
   137
      If your processor has no FPU, then you most probably want this, as it
yann@1
   138
      is faster than emulating the FPU in the kernel.
yann@1
   139
yann@1
   140
endchoice
yann@1
   141
yann@1
   142
config ARCH_FLOAT_SW_LIBFLOAT
yann@1
   143
    bool
yann@1
   144
    prompt "Use libfloat"
yann@1
   145
    default n
yann@1
   146
    depends on ARCH_FLOAT_SW
yann@1
   147
    help
yann@1
   148
      For those targets upporting it, you can use libfloat for the software
yann@1
   149
      floating point emulation.
yann@1
   150
      
yann@1
   151
      Note that some versions of gcc have support code that supersedes libfloat,
yann@1
   152
      while others don't. Known version of gcc that don't have support code are
yann@1
   153
      versions prior to 3.0, and version above 4.0.
yann@1
   154
      
yann@1
   155
      You should check gcc before deciding to use libfloat.
yann@1
   156
yann@1
   157
config TARGET_CFLAGS
yann@1
   158
    string
yann@1
   159
    prompt "Default target CFLAGS"
yann@1
   160
    default ""
yann@1
   161
    help
yann@1
   162
      Used to add specific options when compiling libraries of the toolchain,
yann@1
   163
      that will run on the target (eg. libc.so).
yann@1
   164
      
yann@1
   165
      Note that the options above for CPU, tune, arch and FPU will be
yann@1
   166
      automaticaly used. You don't need to specify them here.
yann@1
   167
      
yann@1
   168
      Leave blank if you don't know better.
yann@1
   169
yann@1
   170
comment "Toolchain options"
yann@1
   171
yann@1
   172
config USE_SYSROOT
yann@1
   173
    bool
yann@1
   174
    prompt "Use sysroot'ed toolchain"
yann@1
   175
    default y
yann@1
   176
    help
yann@1
   177
      Use the 'shinny new' sysroot feature of gcc: libraries split between
yann@1
   178
      prefix/target/sys-root/lib and prefix/target/sys-root/usr/lib
yann@1
   179
      
yann@1
   180
      You definitely want to say 'Y' here. Yes you do. I know you do. Say 'Y'.
yann@1
   181
yann@1
   182
config SHARED_LIBS
yann@1
   183
    bool
yann@1
   184
    prompt "Build shared libraries"
yann@1
   185
    default y
yann@1
   186
    help
yann@1
   187
      Say 'y' here, unless you don't want shared libraries.
yann@1
   188
      
yann@1
   189
      You might not want shared librries if you're building for a target that
yann@1
   190
      don't support it (maybe some nommu targets, for example, or bare metal).
yann@1
   191
yann@1
   192
config TARGET_MULTILIB
yann@1
   193
    bool
yann@1
   194
#    prompt "Enable 'multilib' support (EXPERIMENTAL)"
yann@1
   195
    default n
yann@1
   196
    help
yann@1
   197
      Enable the so-called 'multilib' support.
yann@1
   198
      
yann@1
   199
      With the same toolchain, and on some architectures, you will be able to
yann@1
   200
      build big and little endian binaries, soft- and hard-float, etc...
yann@1
   201
      
yann@1
   202
      See the gcc configure manual at http://gcc.gnu.org/install/configure.html
yann@1
   203
      to see what multilib your target supports.
yann@1
   204
      
yann@1
   205
      It's preferable for now to build two (or more) toolchains, one for each
yann@1
   206
      configuration you need to support (eg. one for thumb and one for ARM,
yann@1
   207
      etc...). You can use the vendor string to diferentiate those toolchains.
yann@1
   208
yann@1
   209
config TARGET_VENDOR
yann@1
   210
    string
yann@1
   211
    prompt "Vendor string"
yann@1
   212
    default "unknown"
yann@1
   213
    help
yann@1
   214
      Vendor part of the machine triplet.
yann@1
   215
      
yann@1
   216
      A triplet is of the form arch-vendor-kernel-system.
yann@1
   217
      You can set the second part, vendor, to whatever you see fit.
yann@1
   218
      Use a single word, or use underscores "_" to separate words.
yann@1
   219
      
yann@1
   220
      Keep the default (unkown) if you don't know better.
yann@1
   221
yann@1
   222
config TARGET_ALIAS
yann@1
   223
    string
yann@1
   224
    prompt "Target alias"
yann@1
   225
    default ""
yann@1
   226
    help
yann@1
   227
      Normaly, you'd call your toolchain component (especially gcc) by
yann@1
   228
      prefixing the target triplet followed by a dash and the component name
yann@1
   229
      (eg. armeb-unknown-linux-uclibc-gcc).
yann@1
   230
      
yann@1
   231
      You can enter a shortcut here. This string will be used to create
yann@1
   232
      symbolic links to the toolchain tools (eg. if you enter "foo-bar" here,
yann@1
   233
      then gcc for your toolchain will also be available as "foo-bar-gcc" along
yann@1
   234
      with the original name).
yann@1
   235
      
yann@1
   236
      You shouldn't need to enter anything here, unless you plan to manually
yann@1
   237
      call the tools (autotools-based ./configure will use the standard name).
yann@1
   238
yann@1
   239
config ARCH
yann@1
   240
    string
yann@1
   241
    default "arm"     if ARCH_ARM
yann@1
   242
    default "mips"    if ARCH_MIPS
yann@1
   243
    default "x86"     if ARCH_x86
yann@1
   244
    default "x86_64"  if ARCH_x86_64
yann@1
   245
yann@1
   246
config BUILD 
yann@1
   247
    string
yann@1
   248
    prompt "Build system triplet"
yann@1
   249
    default ""
yann@1
   250
    help
yann@1
   251
      Canonical name of the machine building the toolchain.
yann@1
   252
      You should leave empty, unless you really now what you're doing.
yann@1
   253
yann@1
   254
config CC_NATIVE
yann@1
   255
    string
yann@1
   256
    prompt "Native gcc"
yann@1
   257
    default "gcc"
yann@1
   258
    help
yann@1
   259
      The native C compiler.
yann@1
   260
      
yann@1
   261
      You can set this to an alternative compiler if you have more than one
yann@1
   262
      installed (eg. gcc is gcc-4.1.1 and you want to use gcc-3.4.6).
yann@1
   263
      
yann@1
   264
      You can leave this empty as well, in which case gcc will be used.
yann@1
   265
yann@1
   266
config CANADIAN
yann@1
   267
    bool
yann@1
   268
    prompt "Canadian build (EXPERIMENTAL)"
yann@1
   269
    default n
yann@1
   270
    help
yann@1
   271
      A canadian build allows to build a compiler on a first machine
yann@1
   272
      (build system), that will run on second machine (host system),
yann@1
   273
      targetting a third machine (target system).
yann@1
   274
      
yann@1
   275
      An example where you'd want a candian cross-compiler is to create
yann@1
   276
      a native compiler for your target. In this case host and target
yann@1
   277
      are the same.
yann@1
   278
yann@1
   279
config HOST
yann@1
   280
    string
yann@1
   281
    prompt "Host system triplet"
yann@1
   282
    default ""
yann@1
   283
    depends on CANADIAN
yann@1
   284
    help
yann@1
   285
      Canonical name of the machine serving as host.
yann@1
   286
yann@1
   287
config HOST_CC
yann@1
   288
    string
yann@1
   289
    prompt "Host system compiler"
yann@1
   290
    default "${CT_HOST}-"
yann@1
   291
    depends on CANADIAN
yann@1
   292
    help
yann@1
   293
      C compiler targeting the host system.
yann@1
   294
      If HOST_CC ends with a dash (-), then it is considered to be the
yann@1
   295
      prefix to gcc (eg. x86-pc-linuc-gnu-).
yann@1
   296
      If it is empty, it is formed by appending '-gcc' to HOST.
yann@1
   297
      Else it is considered to be the complete name of the compiler, with
yann@1
   298
      full path, or without path (provided that it can be found in PATH).
yann@1
   299
yann@1
   300
endmenu