NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1c3eca8cf5
kumquat-buildroot/package/gdb/Config.in

81 lines
2.4 KiB
Plaintext
Raw Normal View History

gdb: introduce BR2_PACKAGE_GDB_ARCH_SUPPORTS Before adding more architecture dependencies to gdb, let's introduce a BR2_PACKAGE_GDB_ARCH_SUPPORTS, to avoid duplicating this list of dependencies between the Config.in comment and the main Config.in option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- Changes since v2: - None Changes since v1: - None
2017-06-03 14:07:45 +02:00
config BR2_PACKAGE_GDB_ARCH_SUPPORTS
bool
default y
gdb: not available on ARM noMMU and OpenRISC Neither gdb nor gdbserver have support for ARM noMMU and OpenRISC, so let's disable gdb on those architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- Changes since v2: - Fixed BR2_openrisc to BR2_or1k in Config.in.host Changes since v1: - Fixed BR2_openrisc to BR2_or1k
2017-06-03 15:39:38 +02:00
depends on !((BR2_arm || BR2_armeb) && BR2_BINFMT_FLAT)
gdb: drop support for Microblaze Microblaze support was never upstreamed in gdb. We currently use a gdb from the Xilinx Github repository, but this gdb is based on 7.6, and has never been updated in the last 4 years. There are no other active branches at https://github.com/Xilinx/gdb/branches. Xilinx has a slightly newer gdb, based on 7.7, available at https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb. However, it's apparently only available in the form of stack of big patches (https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb/files). Currently, gdb on Microblaze fails to build in various conditions: * Against glibc, with "error: conflicting types for 'ps_lgetfpregs'" * Against musl, with "error: unknown type name 'elf_gregset_t'" While those issues can probably be fixed, the fact that there is no active upstream significantly reduces the incentive to fix those problems. Therefore, let's drop support for gdb on Microblaze entirely. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Acked-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-08-03 23:58:12 +02:00
depends on !BR2_microblaze
gdb: introduce BR2_PACKAGE_GDB_ARCH_SUPPORTS Before adding more architecture dependencies to gdb, let's introduce a BR2_PACKAGE_GDB_ARCH_SUPPORTS, to avoid duplicating this list of dependencies between the Config.in comment and the main Config.in option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- Changes since v2: - None Changes since v1: - None
2017-06-03 14:07:45 +02:00
depends on !BR2_nios2
gdb: not available on ARM noMMU and OpenRISC Neither gdb nor gdbserver have support for ARM noMMU and OpenRISC, so let's disable gdb on those architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- Changes since v2: - Fixed BR2_openrisc to BR2_or1k in Config.in.host Changes since v1: - Fixed BR2_openrisc to BR2_or1k
2017-06-03 15:39:38 +02:00
depends on !BR2_or1k
gdb: introduce BR2_PACKAGE_GDB_ARCH_SUPPORTS Before adding more architecture dependencies to gdb, let's introduce a BR2_PACKAGE_GDB_ARCH_SUPPORTS, to avoid duplicating this list of dependencies between the Config.in comment and the main Config.in option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- Changes since v2: - None Changes since v1: - None
2017-06-03 14:07:45 +02:00
Config.in files: unify comments of toolchain option dependencies This patch lines up the comments in Config.in files that clarify which toolchain options the package depends on. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 16:55:32 +02:00
comment "gdb/gdbserver needs a toolchain w/ threads, threads debug"
gdb: introduce BR2_PACKAGE_GDB_ARCH_SUPPORTS Before adding more architecture dependencies to gdb, let's introduce a BR2_PACKAGE_GDB_ARCH_SUPPORTS, to avoid duplicating this list of dependencies between the Config.in comment and the main Config.in option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- Changes since v2: - None Changes since v1: - None
2017-06-03 14:07:45 +02:00
depends on BR2_PACKAGE_GDB_ARCH_SUPPORTS
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 02:04:33 +02:00
depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_HAS_THREADS_DEBUG
config BR2_PACKAGE_GDB
bool "gdb"
packages/g*/Config.in: fix ordering of statements The check-package script when ran gives warnings on ordering issues on all of these Config files. This patch cleans up all warnings related to the ordering in the Config files for packages starting with the letter g in the package directory. The appropriate ordering is: type, default, depends on, select, help See http://nightly.buildroot.org/#_config_files for more information. Signed-off-by: Adam Duskett <Adamduskett@outlook.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-22 19:17:54 +02:00
depends on BR2_TOOLCHAIN_HAS_THREADS && BR2_TOOLCHAIN_HAS_THREADS_DEBUG
gdb: introduce BR2_PACKAGE_GDB_ARCH_SUPPORTS Before adding more architecture dependencies to gdb, let's introduce a BR2_PACKAGE_GDB_ARCH_SUPPORTS, to avoid duplicating this list of dependencies between the Config.in comment and the main Config.in option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- Changes since v2: - None Changes since v1: - None
2017-06-03 14:07:45 +02:00
depends on BR2_PACKAGE_GDB_ARCH_SUPPORTS
gdb: do not allow gdbserver/cross-gdb build in some cases When an external toolchain is used, and the user has chosen to copy the external toolchain gdbserver to the target, then we should allow the user to build a gdbserver and/or a cross-gdb: the ones of the external toolchain should be used. The reasoning is that one must use a gdbserver and cross-gdb of identical versions to be sure that debugging will work properly. Change suggested by Yann E. Morin. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-04-07 02:04:34 +02:00
# 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 \
package: indentation cleanup Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-27 09:25:28 +01:00
(!BR2_PACKAGE_GDB_DEBUGGER && !BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY)
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 02:04:33 +02:00
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"
gdb: do not allow gdbserver/cross-gdb build in some cases When an external toolchain is used, and the user has chosen to copy the external toolchain gdbserver to the target, then we should allow the user to build a gdbserver and/or a cross-gdb: the ones of the external toolchain should be used. The reasoning is that one must use a gdbserver and cross-gdb of identical versions to be sure that debugging will work properly. Change suggested by Yann E. Morin. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-04-07 02:04:34 +02:00
depends on !BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
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 02:04:33 +02:00
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
gdb: drop support for Microblaze Microblaze support was never upstreamed in gdb. We currently use a gdb from the Xilinx Github repository, but this gdb is based on 7.6, and has never been updated in the last 4 years. There are no other active branches at https://github.com/Xilinx/gdb/branches. Xilinx has a slightly newer gdb, based on 7.7, available at https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb. However, it's apparently only available in the form of stack of big patches (https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb/files). Currently, gdb on Microblaze fails to build in various conditions: * Against glibc, with "error: conflicting types for 'ps_lgetfpregs'" * Against musl, with "error: unknown type name 'elf_gregset_t'" While those issues can probably be fixed, the fact that there is no active upstream significantly reduces the incentive to fix those problems. Therefore, let's drop support for gdb on Microblaze entirely. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Acked-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-08-03 23:58:12 +02:00
depends on !BR2_sh
packages/g*/Config.in: fix ordering of statements The check-package script when ran gives warnings on ordering issues on all of these Config files. This patch cleans up all warnings related to the ordering in the Config files for packages starting with the letter g in the package directory. The appropriate ordering is: type, default, depends on, select, help See http://nightly.buildroot.org/#_config_files for more information. Signed-off-by: Adam Duskett <Adamduskett@outlook.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-22 19:17:54 +02:00
select BR2_PACKAGE_NCURSES
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 02:04:33 +02:00
Config.in files: unify comments of toolchain option dependencies This patch lines up the comments in Config.in files that clarify which toolchain options the package depends on. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 16:55:32 +02:00
comment "full gdb on target needs a toolchain w/ wchar"
gdb: drop support for Microblaze Microblaze support was never upstreamed in gdb. We currently use a gdb from the Xilinx Github repository, but this gdb is based on 7.6, and has never been updated in the last 4 years. There are no other active branches at https://github.com/Xilinx/gdb/branches. Xilinx has a slightly newer gdb, based on 7.7, available at https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb. However, it's apparently only available in the form of stack of big patches (https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb/files). Currently, gdb on Microblaze fails to build in various conditions: * Against glibc, with "error: conflicting types for 'ps_lgetfpregs'" * Against musl, with "error: unknown type name 'elf_gregset_t'" While those issues can probably be fixed, the fact that there is no active upstream significantly reduces the incentive to fix those problems. Therefore, let's drop support for gdb on Microblaze entirely. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Acked-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-08-03 23:58:12 +02:00
depends on !BR2_sh
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 02:04:33 +02:00
depends on !BR2_USE_WCHAR
gdb: enable tui support for target package Add a configuration option to compile the gdb target package with the --enable-tui switch. This is done pretty much in the same way as in commit 2474fb0bf1a7 ("host-gdb: enable terminal user interface support"), but for the gdb package on target. This makes sense only when a full debugger is installed on target, not for a gdbserver. [Thomas: remove "default n" since this is the default, adjust the prompt of the option, and rewrap the help text.] Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net> Cc: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-15 22:50:07 +02:00
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
gdb: add support for Python in target gdb This commit adds a new option BR2_PACKAGE_GDB_PYTHON to enable Python support in the target gdb. Since we can assume that the user will be aware that Python is needed to get Python support in gdb, we chose to use a "depends on" dependency instead of a "select" dependency. The other weird thing is the need for a wrapper shell script to replace gdb's provided python-config.py script. See the shell script comment itself for all the details. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-15 22:50:10 +02:00
config BR2_PACKAGE_GDB_PYTHON
bool "Python support"
# Only Python 2.x is supported by gdb for now
depends on BR2_PACKAGE_PYTHON
help
This option enables Python support in the target gdb.
gdb: enable tui support for target package Add a configuration option to compile the gdb target package with the --enable-tui switch. This is done pretty much in the same way as in commit 2474fb0bf1a7 ("host-gdb: enable terminal user interface support"), but for the gdb package on target. This makes sense only when a full debugger is installed on target, not for a gdbserver. [Thomas: remove "default n" since this is the default, adjust the prompt of the option, and rewrap the help text.] Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net> Cc: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-15 22:50:07 +02:00
endif
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 02:04:33 +02:00
endif
Reference in New Issue Copy Permalink