2010-07-28 06:08:16 +08:00
|
|
|
# Generic toolchain options
|
|
|
|
|
|
|
|
|
|
# we want gdb config in the middle of both source and external
|
|
|
|
|
# toolchains, but mconf won't let us source the same file twice,
|
|
|
|
|
# so put it here instead
|
gdb: convert to the package infrastructure
This commit converts gdb to the package infrastructure, and therefore
moves it from toolchain/gdb to package/gdb.
The target package is now visible in "Package selection for the
target" => "Debugging, profiling and benchmark". The main option,
"gdb", forcefully selects the "gdbserver" sub-option by
default. Another sub-option, "full debugger" allows to install the
complete gdb on the target. When this option is enabled, then
"gdbserver" is no longer forcefully selected. This ensures that at
least gdbserver or the full debugger gets built/installed, so that the
package is not a no-op.
The host debugger is still enabled through a configuration option in
"Toolchain". It is now visible regardless of the toolchain type (it
used to be hidden for External Toolchains). The configuration options
relative to the host debugger are now in package/gdb/Config.in.host,
similar to how we have package/binutils/Config.in.host.
Since gdb is now a proper package, it is no longer allowed to 'select
BR2_PTHREADS_DEBUG' to ensure thread debugging is available when
needed. Instead, it now 'depends on
BR2_TOOLCHAIN_HAS_THREADS_DEBUG'. This option, in turn, is selected by
the different toolchain backends when appropriate. The
'BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED' option is removed, since
we no longer need to know when it is allowed to 'select
BR2_PTHREADS_DEBUG'. Also, the 'BR2_PTHREADS_DEBUG' option is moved to
appear right below the thread implementation selection (in the case of
the Buildroot toolchain backend).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-04-07 08:04:33 +08:00
|
|
|
source "package/gdb/Config.in.host"
|
2010-07-28 06:08:16 +08:00
|
|
|
|
2007-02-07 02:19:38 +08:00
|
|
|
config BR2_LARGEFILE
|
toolchain: Improve C library option selection
Turn BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, BR2_USE_WCHAR,
BR2_ENABLE_LOCALE and BR2_PROGRAM_INVOCATION into hidden options.
Then, for Buildroot toolchains, external toolchains and Crosstool-NG
toolchains, provide visible options that selects the hidden options.
This allows :
* To show a different label and help text in the case of Buildroot
toolchain (do you want to enable feature X ?) and in the case of
external toolchain (is feature X available in your toolchain ?)
* To not show any option when a glibc external toolchain is selected
(since glibc is assumed to support all of largefile, IPv6, RPC,
WCHAR, locale and program invocation) and have them all selected in
that case.
There is some amount of duplication between Buildroot toolchain config
options and Crosstool-NG toolchain config options, because kconfig
doesn't allow to source the same Config.in file twice (even if under
mutually exclusive conditions). This duplication is more readable that
the hack that consists in splitting files in multiple pieces.
However, this commit changes the name of the options visible in the
configuration interface, so existing .config files will have to be
updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-14 00:27:37 +08:00
|
|
|
bool
|
2007-02-07 02:19:38 +08:00
|
|
|
|
2007-06-27 00:34:45 +08:00
|
|
|
config BR2_INET_IPV6
|
toolchain: Improve C library option selection
Turn BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, BR2_USE_WCHAR,
BR2_ENABLE_LOCALE and BR2_PROGRAM_INVOCATION into hidden options.
Then, for Buildroot toolchains, external toolchains and Crosstool-NG
toolchains, provide visible options that selects the hidden options.
This allows :
* To show a different label and help text in the case of Buildroot
toolchain (do you want to enable feature X ?) and in the case of
external toolchain (is feature X available in your toolchain ?)
* To not show any option when a glibc external toolchain is selected
(since glibc is assumed to support all of largefile, IPv6, RPC,
WCHAR, locale and program invocation) and have them all selected in
that case.
There is some amount of duplication between Buildroot toolchain config
options and Crosstool-NG toolchain config options, because kconfig
doesn't allow to source the same Config.in file twice (even if under
mutually exclusive conditions). This duplication is more readable that
the hack that consists in splitting files in multiple pieces.
However, this commit changes the name of the options visible in the
configuration interface, so existing .config files will have to be
updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-14 00:27:37 +08:00
|
|
|
bool
|
2007-06-27 00:34:45 +08:00
|
|
|
|
2012-11-04 01:47:49 +08:00
|
|
|
config BR2_TOOLCHAIN_HAS_NATIVE_RPC
|
toolchain: Improve C library option selection
Turn BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, BR2_USE_WCHAR,
BR2_ENABLE_LOCALE and BR2_PROGRAM_INVOCATION into hidden options.
Then, for Buildroot toolchains, external toolchains and Crosstool-NG
toolchains, provide visible options that selects the hidden options.
This allows :
* To show a different label and help text in the case of Buildroot
toolchain (do you want to enable feature X ?) and in the case of
external toolchain (is feature X available in your toolchain ?)
* To not show any option when a glibc external toolchain is selected
(since glibc is assumed to support all of largefile, IPv6, RPC,
WCHAR, locale and program invocation) and have them all selected in
that case.
There is some amount of duplication between Buildroot toolchain config
options and Crosstool-NG toolchain config options, because kconfig
doesn't allow to source the same Config.in file twice (even if under
mutually exclusive conditions). This duplication is more readable that
the hack that consists in splitting files in multiple pieces.
However, this commit changes the name of the options visible in the
configuration interface, so existing .config files will have to be
updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-14 00:27:37 +08:00
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config BR2_USE_WCHAR
|
|
|
|
|
bool
|
2009-01-31 00:28:26 +08:00
|
|
|
|
|
|
|
|
config BR2_ENABLE_LOCALE
|
toolchain: Improve C library option selection
Turn BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, BR2_USE_WCHAR,
BR2_ENABLE_LOCALE and BR2_PROGRAM_INVOCATION into hidden options.
Then, for Buildroot toolchains, external toolchains and Crosstool-NG
toolchains, provide visible options that selects the hidden options.
This allows :
* To show a different label and help text in the case of Buildroot
toolchain (do you want to enable feature X ?) and in the case of
external toolchain (is feature X available in your toolchain ?)
* To not show any option when a glibc external toolchain is selected
(since glibc is assumed to support all of largefile, IPv6, RPC,
WCHAR, locale and program invocation) and have them all selected in
that case.
There is some amount of duplication between Buildroot toolchain config
options and Crosstool-NG toolchain config options, because kconfig
doesn't allow to source the same Config.in file twice (even if under
mutually exclusive conditions). This duplication is more readable that
the hack that consists in splitting files in multiple pieces.
However, this commit changes the name of the options visible in the
configuration interface, so existing .config files will have to be
updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-14 00:27:37 +08:00
|
|
|
bool
|
|
|
|
|
|
2010-12-14 00:27:41 +08:00
|
|
|
config BR2_INSTALL_LIBSTDCPP
|
|
|
|
|
bool
|
|
|
|
|
|
2010-12-14 00:27:44 +08:00
|
|
|
config BR2_TOOLCHAIN_HAS_THREADS
|
|
|
|
|
bool
|
|
|
|
|
|
2011-11-24 21:26:52 +08:00
|
|
|
config BR2_TOOLCHAIN_HAS_THREADS_DEBUG
|
|
|
|
|
bool
|
|
|
|
|
|
2011-05-31 05:56:57 +08:00
|
|
|
config BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
|
|
|
|
|
bool
|
|
|
|
|
|
2009-04-06 17:21:26 +08:00
|
|
|
config BR2_ENABLE_LOCALE_PURGE
|
|
|
|
|
bool "Purge unwanted locales"
|
|
|
|
|
help
|
|
|
|
|
Explicitly specify what locales to install on target. If N
|
|
|
|
|
then all locales supported by packages are installed.
|
|
|
|
|
|
|
|
|
|
config BR2_ENABLE_LOCALE_WHITELIST
|
|
|
|
|
string "Locales to keep"
|
|
|
|
|
default "C en_US de fr"
|
|
|
|
|
depends on BR2_ENABLE_LOCALE_PURGE
|
|
|
|
|
help
|
|
|
|
|
Whitespace seperated list of locales to allow on target.
|
|
|
|
|
Locales not listed here will be removed from the target.
|
|
|
|
|
See 'locale -a' on your host for a list of locales available
|
|
|
|
|
on your build host, or have a look in /usr/share/locale in
|
|
|
|
|
the target file system for available locales.
|
|
|
|
|
|
|
|
|
|
Notice that listing a locale here doesn't guarantee that it
|
|
|
|
|
will be available on the target - That purely depends on the
|
|
|
|
|
support for that locale in the selected packages.
|
|
|
|
|
|
Add support to generate locale data
In order to use locale support on a Linux system, you need locale data
to be present:
* on a (e)glibc based system, this data is typically in the
/usr/lib/locale/locale-archive file, which can be created and
extended using the localedef program
* on an uClibc based system, the set of supported locales is defined
at build time by an uClibc configuration option.
This patch implements generating locale data for the following cases:
* Internal toolchain
* External toolchain based on (e)glibc. uClibc external toolchains
are not supported, because with uClibc, the set of supported
locales is defined at build time. CodeSourcery and Linaro
toolchains have been tested, Crosstool-NG toolchains are believed
to work properly as well.
* Toolchains built using the Crosstool-NG backend, but only (e)glibc
toolchains.
This feature was runtime tested with internal uClibc toolchain,
CodeSourcery ARM toolchain and Linaro ARM toolchain, thanks to a
simple C program that shows the data and a gettext translated message.
Note that this option differs from the "purge locales" option, which
is responsible for removing translation files and other locale stuff
installed by packages. At some point in the future, we may want to
clarify the respective roles of those options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-05-08 12:39:22 +08:00
|
|
|
config BR2_GENERATE_LOCALE
|
|
|
|
|
string "Generate locale data"
|
|
|
|
|
default ""
|
|
|
|
|
# Pre-built uClibc external toolchains and uClibc toolchains
|
|
|
|
|
# built by the Crosstool-NG backend cannot be supported,
|
|
|
|
|
# because the list of locales to support must be defined at
|
|
|
|
|
# build time.
|
|
|
|
|
depends on \
|
|
|
|
|
BR2_TOOLCHAIN_BUILDROOT || \
|
2013-07-01 03:29:09 +08:00
|
|
|
BR2_TOOLCHAIN_USES_GLIBC
|
Add support to generate locale data
In order to use locale support on a Linux system, you need locale data
to be present:
* on a (e)glibc based system, this data is typically in the
/usr/lib/locale/locale-archive file, which can be created and
extended using the localedef program
* on an uClibc based system, the set of supported locales is defined
at build time by an uClibc configuration option.
This patch implements generating locale data for the following cases:
* Internal toolchain
* External toolchain based on (e)glibc. uClibc external toolchains
are not supported, because with uClibc, the set of supported
locales is defined at build time. CodeSourcery and Linaro
toolchains have been tested, Crosstool-NG toolchains are believed
to work properly as well.
* Toolchains built using the Crosstool-NG backend, but only (e)glibc
toolchains.
This feature was runtime tested with internal uClibc toolchain,
CodeSourcery ARM toolchain and Linaro ARM toolchain, thanks to a
simple C program that shows the data and a gettext translated message.
Note that this option differs from the "purge locales" option, which
is responsible for removing translation files and other locale stuff
installed by packages. At some point in the future, we may want to
clarify the respective roles of those options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-05-08 12:39:22 +08:00
|
|
|
help
|
|
|
|
|
Generate support for a list of locales. Locales can be
|
|
|
|
|
specified with or without encoding, when no encoding is
|
|
|
|
|
specified, UTF-8 is assumed. Examples of locales: en_US,
|
|
|
|
|
fr_FR.UTF-8.
|
|
|
|
|
|
2010-05-25 03:17:50 +08:00
|
|
|
# glibc and eglibc directly include gettext, so a separatly compiled
|
|
|
|
|
# gettext isn't needed and shouldn't be built to avoid conflicts. Some
|
|
|
|
|
# packages always need gettext, other packages only need gettext when
|
|
|
|
|
# locale support is enabled. See the documentation for how packages
|
|
|
|
|
# should rely on the following two options.
|
|
|
|
|
|
Add a BR2_NEEDS_GETTEXT option
When using an external toolchain that uses the glibc or eglibc C
libraries, compiling a separate gettext and libintl is not needed and
is even a source of confusion, causing build failures. These build
failures are due to the fact that when libintl is compiled, it
replaces the C library libintl.h by its own, which does #define
gettext libintl_gettext. Then, when packages want to use gettext,
autoconf realize that gettext is available in the C library and
therefore do not add -lintl to the LDFLAGS, causing the build failure
because the program has been compiled to use libintl_gettext but this
function is not available.
Therefore, we should only use gettext if a uClibc internal toolchain
or a uClibc external toolchain. If an external glibc toolchain is
used, gettext shouldn't be used.
In order to implement that, we introduce the BR2_NEEDS_GETTEXT option,
which is hidden to the user, and whose value is computed automatically
from the rest of the configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-05-14 04:21:08 +08:00
|
|
|
config BR2_NEEDS_GETTEXT
|
|
|
|
|
bool
|
2013-07-01 03:29:09 +08:00
|
|
|
default y if BR2_TOOLCHAIN_USES_UCLIBC
|
2010-05-25 03:17:50 +08:00
|
|
|
|
|
|
|
|
config BR2_NEEDS_GETTEXT_IF_LOCALE
|
|
|
|
|
bool
|
|
|
|
|
default y if (BR2_NEEDS_GETTEXT && BR2_ENABLE_LOCALE)
|
Add a BR2_NEEDS_GETTEXT option
When using an external toolchain that uses the glibc or eglibc C
libraries, compiling a separate gettext and libintl is not needed and
is even a source of confusion, causing build failures. These build
failures are due to the fact that when libintl is compiled, it
replaces the C library libintl.h by its own, which does #define
gettext libintl_gettext. Then, when packages want to use gettext,
autoconf realize that gettext is available in the C library and
therefore do not add -lintl to the LDFLAGS, causing the build failure
because the program has been compiled to use libintl_gettext but this
function is not available.
Therefore, we should only use gettext if a uClibc internal toolchain
or a uClibc external toolchain. If an external glibc toolchain is
used, gettext shouldn't be used.
In order to implement that, we introduce the BR2_NEEDS_GETTEXT option,
which is hidden to the user, and whose value is computed automatically
from the rest of the configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-05-14 04:21:08 +08:00
|
|
|
|
2011-01-10 22:28:41 +08:00
|
|
|
config BR2_USE_MMU
|
2012-11-15 11:53:51 +08:00
|
|
|
bool "Enable MMU support" if BR2_arm || BR2_armeb || BR2_mips || BR2_mipsel || BR2_sh || BR2_xtensa
|
2011-02-07 13:49:11 +08:00
|
|
|
default y if !BR2_bfin
|
2011-01-10 22:28:41 +08:00
|
|
|
help
|
|
|
|
|
If your target has a MMU, you should say Y here. If you
|
|
|
|
|
are unsure, just say Y.
|
|
|
|
|
|
2009-01-31 00:28:26 +08:00
|
|
|
config BR2_TARGET_OPTIMIZATION
|
|
|
|
|
string "Target Optimizations"
|
2010-06-14 20:36:04 +08:00
|
|
|
default "-pipe"
|
2009-01-31 00:28:26 +08:00
|
|
|
help
|
|
|
|
|
Optimizations to use when building for the target host.
|
2010-06-14 20:36:04 +08:00
|
|
|
NOTE: gcc optimization level is defined in build options.
|
2011-06-23 17:21:21 +08:00
|
|
|
|
|
|
|
|
config BR2_TARGET_LDFLAGS
|
|
|
|
|
string "Target linker options"
|
|
|
|
|
help
|
2012-01-14 03:23:23 +08:00
|
|
|
Extra options to pass to the linker when building for the target.
|
2013-01-13 12:52:13 +08:00
|
|
|
|
|
|
|
|
config BR2_ECLIPSE_REGISTER
|
|
|
|
|
bool "Register toolchain within Eclipse Buildroot plug-in"
|
|
|
|
|
help
|
|
|
|
|
This options tells Buildroot to generate the necessary
|
|
|
|
|
configuration files to make your toolchain appear within
|
|
|
|
|
Eclipse, through the Eclipse Buildroot plugin.
|
