kumquat-buildroot/package/gdb/Config.in
Adam Duskett a607efc6d3 package/gdb: remove python2 support
Since at least gdb 7.8, python3 support has been available. As part of
the progressive retiring of python2 support, it is time to drop its
support in gdb by:

- Removing BR2_PACKAGE_HOST_GDB_PYTHON in package/gdb/Config.in.host
  and removing the choice to leave just a BR2_PACKAGE_HOST_GDB_PYTHON3
  option.

- Adding BR2_PACKAGE_HOST_GDB_PYTHON to Config.in.legacy

- Changing depends on BR2_PACKAGE_PYTHON || BR2_PACKAGE_PYTHON3 to
  depends on BR2_PACKAGE_PYTHON3 in package/gdb/Config.in

Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-01-13 21:27:34 +01:00

87 lines
2.7 KiB
Plaintext

config BR2_PACKAGE_GDB_ARCH_SUPPORTS
bool
default y
depends on !((BR2_arm || BR2_armeb) && BR2_BINFMT_FLAT)
depends on !BR2_microblaze
depends on !BR2_or1k
depends on !BR2_nds32
comment "gdb/gdbserver needs a toolchain w/ threads, threads debug"
depends on BR2_PACKAGE_GDB_ARCH_SUPPORTS
depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_HAS_THREADS_DEBUG
comment "gdb/gdbserver >= 8.x needs a toolchain w/ C++, gcc >= 4.8"
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
config BR2_PACKAGE_GDB
bool "gdb"
depends on BR2_TOOLCHAIN_HAS_THREADS && BR2_TOOLCHAIN_HAS_THREADS_DEBUG
depends on BR2_PACKAGE_GDB_ARCH_SUPPORTS
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
depends on BR2_INSTALL_LIBSTDCPP
# When the external toolchain gdbserver is copied to the
# target, we don't allow building a separate gdbserver. The
# one from the external toolchain should be used.
select BR2_PACKAGE_GDB_SERVER if \
(!BR2_PACKAGE_GDB_DEBUGGER && !BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY)
help
GDB, the GNU Project debugger, allows you to see what is
going on `inside' another program while it executes -- or
what another program was doing at the moment it crashed.
This option allows to build gdbserver and/or the gdb
debugger for the target.
For embedded development, the most common solution is to
build only 'gdbserver' for the target, and use a cross-gdb
on the host. See BR2_PACKAGE_HOST_GDB in the Toolchain menu
to enable one. Notice that external toolchains often provide
their own pre-built cross-gdb and gdbserver binaries.
http://www.gnu.org/software/gdb/
if BR2_PACKAGE_GDB
config BR2_PACKAGE_GDB_SERVER
bool "gdbserver"
depends on !BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
help
Build the gdbserver stub to run on the target.
A full gdb is needed to debug the progam.
config BR2_PACKAGE_GDB_DEBUGGER
bool "full debugger"
depends on BR2_USE_WCHAR
depends on !BR2_sh
depends on !BR2_csky
select BR2_PACKAGE_GMP if BR2_GDB_VERSION_11
select BR2_PACKAGE_NCURSES
comment "full gdb on target needs a toolchain w/ wchar"
depends on !BR2_sh
depends on !BR2_USE_WCHAR
if BR2_PACKAGE_GDB_DEBUGGER
config BR2_PACKAGE_GDB_TUI
bool "TUI support"
help
This option enables terminal user interface (TUI) for gdb
"The GDB Text User Interface (TUI) is a terminal interface
which uses the curses library to show the source file, the
assembly output, the program registers and GDB commands in
separate text windows."
https://sourceware.org/gdb/current/onlinedocs/gdb/TUI.html
config BR2_PACKAGE_GDB_PYTHON
bool "Python support"
depends on BR2_PACKAGE_PYTHON3
help
This option enables Python support in the target gdb.
endif
endif