| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some users seem to interpret:
make ctng-menuconfig
as being a value that can be fit for the ct-ng config file.
Clarify that it is a command to run, not a possible value.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the version of glibc to be used, since older versions are
broken with the currently-used binutils versions.
Fixes build issues ending with:
tmpfs/ccvkz3ro.s:33: Error: CFI instruction used without
previous .cfi_startproc
This new version does not have RPC support, so update the Config.in.
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
|
|
|
|
|
| |
The BR2_INET_RPC has for a long time been a not very descriptive
configuration option name, and with the advent of non-RPC glibc
toolchains and the apparition of libtirpc, we really need to rename it
to something more sensible, BR2_TOOLCHAIN_HAS_NATIVE_RPC.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
|
| |
So we're in sync with the internal toolchain.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the BR option and enable the configuration setting in the
uClibc defconfigs.
The BR2_PROGRAM_INVOCATION option only adds very little overhead to
uClibc, and we have a number of packages needing it, so simply always
enable it - Simplifying the kconfig logic and the number of choices
users have to make.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
|
|
|
|
|
| |
Currently, the bundled CT-NG config file has no C library configured.
It is quite complex to add and/or munge options in this case.
Now, with one config file per libc familly, it becomes easier.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
|
| |
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having BR2_GCC_CROSS_CXX and BR2_INSTALL_LIBSTDCPP, with
BR2_GCC_CROSS_CXX not being visible (and therefore being useless),
let's just keep BR2_INSTALL_LIBSTDCPP to enable C++ in the toolchain
and install C++ libraries on the target.
We also take that opportunity to make BR2_INSTALL_LIBSTDCPP an hidden
option, which is selected by an option in Buildroot toolchain support
or an option in External toolchain support, just as we did for other
toolchain features.
Some work definitely remains to be done :
- The name BR2_INSTALL_LIBSTDCPP is ugly, but we keep it for the
moment in order to avoid changing all packages.
- We should clarify the other language-related options (Fortran,
Java, Objective-C, etc.).
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>
|
|
|
|
|
|
|
|
|
|
| |
We already handle the stripping of libraries in $(TARGET_DIR) at the
global level, so there's no need to have toolchain-specific option and
code for this.
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
[Peter: indent Config.in, shuffle make targets around]
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|