mirror of
https://github.com/crosstool-ng/crosstool-ng.git
synced 2024-12-24 23:16:42 +00:00
b8e64a0c08
This commit adds support for the avr-libc C library. According to the project page at http://www.nongnu.org/avr-libc , the avr-libc package provides a subset of the standard C library for Atmel AVR 8-bit RISC microcontrollers. In addition, the library provides the basic startup code needed by most applications. Support for this library in crosstool-ng is only enabled for the AVR 8-bit target. The avr-libc manual and most distributions build the AVR 8-bit gcc toolchain with the "avr" (non-canonical) target. Some experimentation also led to the conclusion that other (canonical) targets are not very well supported, so we force the "avr" target for crosstool-ng as well. The manual also recommends building avr-libc after the final gcc build. To accomplish this with crosstool-ng, a new do_libc_post_cc step is added, in which currently only avr-libc performs its build, and is a no-op for the other libc options. Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
314 lines
9.1 KiB
Plaintext
314 lines
9.1 KiB
Plaintext
menu "Toolchain options"
|
|
|
|
comment "General toolchain options"
|
|
|
|
config FORCE_SYSROOT
|
|
bool
|
|
default y if !OBSOLETE
|
|
select USE_SYSROOT
|
|
|
|
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/sysroot/lib and prefix/target/sysroot/usr/lib
|
|
|
|
You definitely want to say 'Y' here. Yes you do. I know you do. Say 'Y'.
|
|
|
|
config SYSROOT_NAME
|
|
string
|
|
prompt "sysroot directory name" if ! BACKEND
|
|
depends on USE_SYSROOT
|
|
default "sysroot"
|
|
help
|
|
Enter the base name of the sysroot directory. Usually, this simply
|
|
is 'sysroot' (the default) or 'sys-root'.
|
|
|
|
You are free to enter anything here, except for spaces, and '/'
|
|
(see SYSROOT_DIR_PREFIX, below). If you leave this empty, then the
|
|
default 'sysroot' is used.
|
|
|
|
config SYSROOT_DIR_PREFIX
|
|
string
|
|
prompt "sysroot prefix dir (READ HELP)" if ! BACKEND
|
|
depends on USE_SYSROOT
|
|
default ""
|
|
help
|
|
*
|
|
* Unless you really know you need that, leave it empty!
|
|
*
|
|
|
|
This string will be interpreted as a directory component to be added
|
|
to the sysroot path, just before the actual sysroot directory.
|
|
|
|
In fact, the sysroot path is constructed as:
|
|
${CT_PREFIX_DIR}/${CT_TARGET}/${CT_SYSROOT_DIR_PREFIX}/${CT_SYSROOT_NAME}
|
|
|
|
config WANTS_STATIC_LINK
|
|
bool
|
|
|
|
config STATIC_TOOLCHAIN
|
|
bool
|
|
prompt "Build Static Toolchain"
|
|
select WANTS_STATIC_LINK
|
|
help
|
|
Build static host binaries.
|
|
|
|
If you wish to move the toolchain to another host, and you are not
|
|
confident that this host has the required versions of system libs, then
|
|
you can say 'Y' here, and all the host tools will be linked statically.
|
|
|
|
The impacted tools are:
|
|
- the cross-binutils (GNU binutils, elf2flt)
|
|
- the cross-compiler (gcc)
|
|
- the cross-debugger (gdb)
|
|
|
|
The default is 'N', to build dynamicaly-linked host binaries.
|
|
|
|
NOTE: this has no connection to whether the target libraries will be
|
|
dynamic or static. This only applies to the tools themselves.
|
|
|
|
config TOOLCHAIN_PKGVERSION
|
|
string
|
|
prompt "Toolchain ID string"
|
|
default ""
|
|
help
|
|
Specify a string that identifies your package. You may wish to include
|
|
a build number or build date. This version string will be included in
|
|
the output of gcc --version, and also in binutils, glibc, gdb and
|
|
gdbserver.
|
|
|
|
If this string is left empty, the actual package version will be:
|
|
"crosstool-NG ${CT_VERSION}"
|
|
Otherwise, it will be:
|
|
"crosstool-NG ${CT_VERSION} - ${CT_TOOLCHAIN_PKGVERSION}"
|
|
|
|
This is passed to the configure flag --with-pkgversion.
|
|
|
|
config TOOLCHAIN_BUGURL
|
|
string
|
|
prompt "Toolchain bug URL"
|
|
default ""
|
|
help
|
|
Specify the URL that users should visit if they wish to report a bug.
|
|
|
|
comment "Tuple completion and aliasing"
|
|
|
|
config TARGET_VENDOR
|
|
string
|
|
prompt "Tuple's vendor string"
|
|
depends on !LIBC_avr_libc
|
|
default "unknown"
|
|
help
|
|
Vendor part of the target tuple.
|
|
|
|
A tuple 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.
|
|
Use neither dash nor space, as it breaks things.
|
|
|
|
Keep the default (unknown) if you don't know better.
|
|
|
|
config TARGET_ALIAS_SED_EXPR
|
|
string
|
|
prompt "Tuple's sed transform"
|
|
default ""
|
|
help
|
|
Normally, you'd call your toolchain components (especially gcc) by
|
|
prefixing the target tuple followed by a dash and the component name
|
|
(eg. armeb-unknown-linux-uclibc-gcc).
|
|
|
|
You can enter here a sed expression to be applied to ${CT_TARGET} to
|
|
create an alias for your toolchain.
|
|
|
|
For example, "s/${CT_TARGET_VENDOR}/foobar/" (without the double quotes)
|
|
will create the armeb-foobar-linux-uclibc alias to the above-mentioned
|
|
toolchain.
|
|
|
|
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 TARGET_ALIAS
|
|
string
|
|
prompt "Tuple's alias"
|
|
default ""
|
|
help
|
|
Normally, you'd call your toolchain components (especially gcc) by
|
|
prefixing the target tuple 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).
|
|
|
|
comment "Toolchain type"
|
|
|
|
choice
|
|
bool
|
|
prompt "Type"
|
|
default CROSS
|
|
|
|
config NATIVE
|
|
bool
|
|
prompt "Native (NO CODE!) (EXPERIMENTAL)"
|
|
depends on EXPERIMENTAL
|
|
help
|
|
Build a native toolchain.
|
|
See: "docs/6 - Toolchain types.txt"
|
|
|
|
config CROSS
|
|
bool
|
|
prompt "Cross"
|
|
help
|
|
Build a cross-toolchain.
|
|
See: "docs/6 - Toolchain types.txt"
|
|
|
|
config CROSS_NATIVE
|
|
bool
|
|
prompt "Cross-native (NO CODE!) (EXPERIMENTAL)"
|
|
depends on EXPERIMENTAL
|
|
help
|
|
Build a cross-native toolchain.
|
|
See: "docs/6 - Toolchain types.txt"
|
|
|
|
config CANADIAN
|
|
bool
|
|
prompt "Canadian"
|
|
help
|
|
Build a canadian-toolchain.
|
|
See: "docs/6 - Toolchain types.txt"
|
|
|
|
endchoice
|
|
|
|
config TOOLCHAIN_TYPE
|
|
string
|
|
default "native" if NATIVE
|
|
default "cross" if CROSS
|
|
default "cross-native" if CROSS_NATIVE
|
|
default "canadian" if CANADIAN
|
|
|
|
comment "Build system"
|
|
|
|
config BUILD
|
|
string
|
|
prompt "| Tuple (READ HELP!)"
|
|
default ""
|
|
help
|
|
Canonical name of the machine building the toolchain.
|
|
You should leave empty, unless you really know what you're doing.
|
|
|
|
config BUILD_PREFIX
|
|
string
|
|
prompt "| Tools prefix (READ HELP!)"
|
|
default ""
|
|
help
|
|
If you have your *build system* tools in a weird location, and/or
|
|
they have an unusual prefix, enter it here.
|
|
|
|
Usually, you should leave that empty!
|
|
|
|
Eg.:
|
|
If your *build* gcc is /opt/build-tools/bin/weird-gcc then you
|
|
should enter:
|
|
/opt/build-tools/bin/weird-
|
|
|
|
If your *build* gcc is /opt/build-tools/bin/weird-gcc and
|
|
/opt/build-tools/bin is in your PATH, you should enter:
|
|
weird-
|
|
|
|
If your *build* gcc is /opt/build-tools/bin/gcc then you
|
|
should enter (do not forget to add the trailing '/'):
|
|
/opt/build-tools/bin/
|
|
|
|
config BUILD_SUFFIX
|
|
string
|
|
prompt "| Tools suffix (READ HELP!)"
|
|
default ""
|
|
help
|
|
If your *build system* tools have an unusual suffix, enter it
|
|
here.
|
|
|
|
Usually, you should leave that empty!
|
|
|
|
Eg.:
|
|
If your 'default' gcc is gcc 4.3.1, but you also have gcc-3.4.2
|
|
installed as gcc-3.4, then you should enter:
|
|
-3.4
|
|
|
|
It can happen that some of the tools have a suffix, when others
|
|
don't, eg. you can have 'gcc-3.4' and 'ar'. crosstool-NG accounts
|
|
for that by checking the tools without the suffix in case it can
|
|
not find some of the tool.
|
|
|
|
if CANADIAN
|
|
|
|
comment "Host system"
|
|
|
|
config HOST
|
|
string
|
|
prompt "| Tuple (READ HELP!)"
|
|
default ""
|
|
help
|
|
Canonical name of the machine running the toolchain.
|
|
|
|
config HOST_PREFIX
|
|
string
|
|
prompt "| Tools prefix (READ HELP!)"
|
|
default ""
|
|
help
|
|
If you have your *host system* tools in a weird location, and/or
|
|
they have an unusual prefix, enter it here.
|
|
|
|
Usually, you should leave that empty!
|
|
|
|
Eg.:
|
|
If your *host* gcc is /opt/host-tools/bin/weird-gcc then you
|
|
should enter:
|
|
/opt/host-tools/bin/weird-
|
|
|
|
If your *host* gcc is /opt/host-tools/bin/weird-gcc and
|
|
/opt/host-tools/bin is in your PATH, you should enter:
|
|
weird-
|
|
|
|
If your *host* gcc is /opt/host-tools/bin/gcc then you
|
|
should enter (do not forget to add the trailing '/'):
|
|
/opt/host-tools/bin/
|
|
|
|
config HOST_SUFFIX
|
|
string
|
|
prompt "| Tools suffix (READ HELP!)"
|
|
default ""
|
|
help
|
|
If your *host system* tools have an unusual suffix, enter it
|
|
here.
|
|
|
|
Usually, you should leave that empty!
|
|
|
|
Eg.:
|
|
If your 'default' gcc is gcc 4.3.1, but you also have gcc-3.4.2
|
|
installed as gcc-3.4, then you should enter:
|
|
-3.4
|
|
|
|
It can happen that some of the tools have a suffix, when others
|
|
don't, eg. you can have 'gcc-3.4' and 'ar'. crosstool-NG accounts
|
|
for that by checking the tools without the suffix in case it can
|
|
not find some of the tool.
|
|
|
|
endif # CANADIAN
|
|
|
|
comment "Misc options"
|
|
|
|
config TOOLCHAIN_ENABLE_NLS
|
|
bool
|
|
prompt "Enable nls"
|
|
help
|
|
Say 'Y' here to enable native language support (nls).
|
|
|
|
endmenu
|