This commit fixes the exact same problem than
21a0c11a90, but for the gdbserver
build. The problem is that when you use the Crosstool-NG toolchain
backend, gawk gets built as a dependency of Crosstool-NG. So the gdb
configure scripts detects it, and assumes it is in the PATH (because
the gdb configure step gets run with TARGET_MAKE_ENV).
But then, the build fails, because it tries to run gawk, but gawk
isn't in the PATH, because we forget to use this TARGET_MAKE_ENV
variable when building gdbserver.
Fixes http://autobuild.buildroot.org/results/d0173de533b5e2fffed2eff7327a502ed2d787cd/build-end.log
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When building gdb for the host, we properly pass the PATH (through
HOST_CONFIGURE_OPTS) during the configure step, but we forget to do so
for the compilation step.
The result of this is that when the Crosstool-NG backend is used, gawk
is built and installed in $(HOST_DIR), as a dependency of the
crosstool-ng package.
Then, the host gdb configure script detects this gawk binary
($(HOST_DIR) is in the PATH), and assumes gawk is
available. Unfortunately, during the compilation step, it fails to
find the expected gawk binary, because $(HOST_DIR) is no longer in the
PATH. This causes the following build failure:
http://autobuild.buildroot.org/results/067d0c2ea01673ba98ec11de2426f1ab92dac800/build-end.log
In order to fix this, we simply call the compilation step of gdb for
the host with $(HOST_MAKE_ENV), as it should have been done from the
beginning.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Fix build breakage, use the version of the ptrace header file in asm
instead of sys. Also, fix GDB running on 64 bit hosts. GDB was using
unsigned long for 32-bit registers, but unsigned long is 64 bit on
64-bit hosts.
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Except for architecture and processor names, buildroot uses capitalized
configuration names, so change the macro names for xtensa to follow that
standard.
Change the overlay file to have a subdirectory for each component
(gdb, binutils, gcc, etc.) to make it more future-prove.
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Xtensa is a configurable processor architecture, which allows to define
additional instructions and registers. The required variant specific
information for the toolchain is delivered in an 'overlay' file, which
needs to be 'untarred' to the corresponding directories after the
source is installed and patched.
This patch provides support for binutils, gcc, and gdb with a very
limited changes to the build scripts. These additions are only executed
for the Xtensa architecture and have no effect on other architectures.
[Thomas: rebased on top of the 'arch: improve definition of gcc mtune,
mcpu, etc.' patch, and changed 'Target ABI' to 'Target Architecture
Variant'].
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When an external toolchain without thread debug is used, the gdb
package can be selected, but no version can be choosen, since none
match any of the requirements. This leads Buildroot to try to build
gdb for the target without a version being defined, as in the
following build log:
http://autobuild.buildroot.org/results/84e8fd2df0cc22448052a572c2e9a6e03dd137eb/build-end.log
To fix this, we adjust the dependencies of the BR2_PACKAGE_GDB option
so that the package as a whole is not selectable when the required
conditions are not met. Basically, we have the choice of:
* Having a toolchain that supports thread debugging, which is needed
for gdb >= 7.x
* Having BR2_DEPRECATED enabled, which allows gdb 6.8 to be selected,
which doesn't require thread debugging
* Using bfin, since this architectures has a special old gdb version
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As stated in commit 555c2585bf, the
Xtensa architecture has been introduced in 2009 and never changed
since its initial introduction. It requires some special handling that
is a bit annoying, and despite our call to the initial developers, and
the announcement of the deprecation of the architecture during the
2012.05, nothing has happened. Therefore, drop support for this
architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: me
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Instead of providing two variables, make GNU_TARGET_NAME give the real
target name, and remove REAL_GNU_TARGET_NAME altogether.
Signed-off-by: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When the crosstool-ng backend is used, host-gawk is built as a
dependency of the crosstool-ng package, and therefore an host 'gawk'
binary is installed in $(HOST_DIR).
When the target gdb package is also selected, this unfortunately leads
to a build failure, as reported on
http://buildroot.humanoidz.org/results/f19c0499d08212d8b5100fa9434e1197092957db/build-end.log.
The problem is that the ./configure of gdb detects gawk in the PATH,
but at compile time, it fails to find gawk. This is due to the fact
that the gdb compilation process is started without the correct path.
This patch fixes this by passing $(TARGET_MAKE_ENV) in the environment
of the gdb compilation process.
A better fix would be to switch gdb to the AUTOTARGETS infrastructure
in the future.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This modifies the definition of DOWNLOAD to receive two arguments:
the first one is the full URL of the file to download, whereas the second
(and optional) is the name the file will have once downloaded.
Same thing with the SOURCE_CHECK_WGET and SCP functions.
All calls to these functions have been changed to the shortest form of
the new API, except for toolchains acquisition. Since there is quite a
number of different toolchains this call to DOWNLOAD is better set to the
generic one.
Signed-off-by: Alvaro G. M <alvaro.gamez@hazent.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Stephan Hoffmann <sho@relinux.de>
Downloading Microblaze LE toolchain works on a clean install
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When an external toolchain is used, it is very likely that it contains
a pre-built version of a gdbserver that has the same version as the
cross-gdb included in the external toolchain. So, we now provide an
option that allows to copy this pre-built gdbserver to the target.
As the location of the gdbserver in the external toolchain is not
standardized, we only support the CodeSourcery and Crosstool-NG
layouts for the moment. Other locations can be added later.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Similar to how we do for target (ee39d53ce3ee (Fix GDB BFD test linking)).
Gdb comes with an embedded copy of libiberty, but binutils also installs
libiberty.a into HOST_DIR. The gdb configure script tries to link against
this one rather than the gdb version when it checks for ELF support.
This may fail if those versions are not compatible, leading to obscure
error messages from gdb at runtime such as:
I'm sorry, Dave, I can't do that. Symbol format `elf32-$ARCH' unknown.
Fix it by forcing ELF support.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Newer versions of GDB need pthread debugging support if threads are
enabled, which is always the case for glibc but is a configure option
for uClibc.
We have solved this for internal toolchains by selecting the
BR2_PTHREAD_DEBUG option from the GDB selection if needed, but as this
option isn't available when ctng/external toolchains are used, mconf
prints ugly warnings and the build may fail if an external uClibc
toolchain without pthread debugging support is used.
Fix it by introducing 2 more hidden config options:
- BR2_TOOLCHAIN_HAS_THREADS_DEBUG
- BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED
The first tells us if the toolchain HAS pthreads debugging support,
and is checked by check_uclibc_feature in helper.mk for external uClibc
based toolchains.
The second tells us if the toolchain is ABLE TO provide pthreads debugging
support if threads are enabled, either because it's an internal toolchain
where we can force enable it or an external glibc/eglibc toolchain or
uClibc with the option enabled.
Crosstool-ng forcibly enables this support, so those will always work.
The preconfigured uClibc-based toolchains we have also all enable it.
Finally, show a comment if this isn't the case so the (external toolchain)
user knows why. This is placed outside the choice option, as menuconfig
has a bug where it doesn't show choice selections which only contain
comments.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Compiling gdb for the target requires thread support in the C library,
otherwise:
/home/test/outputs/test-888/toolchain/gdb-7.3.1/gdb/gdb_thread_db.h:37:21: fatal error: pthread.h: No such file or directory
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The gdb debugger does not have support for running as the native
debugger on the SuperH architecture:
configure: error: "*** Gdb does not support native target sh4-unknown-linux-gnu"
See also http://lists.debian.org/debian-superh/2010/04/msg00000.html.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The gdb tarballs have been re-released after a GPL compliance
issue was found:
http://sourceware.org/ml/gdb/2011-09/msg00030.html
So all versions were re-packaged.
In the process, an 'a' was appended to the version strings, and
unlike the binutils people, the gdb folks are not inclined in
providing legacy symlinks:
http://sourceware.org/ml/gdb/2011-09/msg00036.html
So, this patch fixes the issue by renaming version strings. It is to be
noted that, although the versions got bumped to include an 'a' at the end,
the directory contained in the tarball is still named after the version
string without the 'a'. For example:
- old version : 6.6
- new version : 6.6a
- tarball name : gdb-6.6a.tar.bz2
- directory name : gdb-6.6/
In fact, it does not pose any problem for buildroot, as the extract process
explicitly mkdirs the directory to extract into, *and* strips the first level
of the tree extracted from the tarball.
[Peter: fixup patch to apply to head, don't rename config symbols]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For some tarballs of gdb (see next patch), the extracted directory is
*not* named after the version string (eg. gdb-6.6a extract into gdb-6.6/)
Create the appropriate directory first, then use --strip-{components,path}
when extracting gdb (the same way it is done for the generic package
infrastructure).
At the same time, get rid of the snapshot special case, because:
1- it's no longer available in the menu
2- it would be handled by the above change
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
this version fixes compilation issue on some old build systems like
openSUSE 10.3 saying some host libraries were too old
[Peter: drop bugfix number from config name, similar to kernel-headers]
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The CONFIG_UPDATE macro is no longer defined in
package/gnuconfig/gnuconfig.mk, but instead in
package/Makefile.autotools.in. It it also changed a little bit to take
the directory of the package sources as argument, and the AUTOTARGETS
infrastructure is updated to use this macro.
[Peter: drop echo in CONFIG_UPDATE]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The name "patch-kernel.sh" is a bit stupid, since this script is used
to patch everything in Buildroot, not only kernel trees.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This patch fixes the following error when using GDB with gdbserver:
warning: Can not parse XML target description; XML support was disabled at compile time
Remote 'g' packet reply is too long: <very long line of hex chars>
[remote debugging does not work]
Use $(HOST_CONFIGURE_OPTS) so expat is found.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This requires removing "deprecated" markings from gdb-6.6, but this isn't
that big of a deal. That is the last version with Blackfin support at the
moment and we're in the process of getting mainlined.
[Peter: only mark as undeprecated on bfin]
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since the top level takes care of stripping for us, and some file formats
cannot be stripped safely (like FLAT which will error out), simply punt
the manual stripping from the gdb package.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The cross-gdb is supposed to be part of the external toolchain, so
Buildroot does not need to build it. Moreover, GDB_HOST build
currently fail with:
ln -snf ../../bin/arm-unknown-linux-gnueabi-gdb \
/home/test/outputs/test-48/staging/usr/arm-unknown-linux-gnueabi/bin/gdb
ln: creating symbolic link `/home/test/outputs/test-48/staging/usr/arm-unknown-linux-gnueabi/bin/gdb': No such file or directory
And even worse: they overwrite the cross-gdb of the external
toolchain!
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that TARGET_CC contains several space-separated words, it must be
used quoted everywhere.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
These are ancient (2006) and upstream strongly discourage using them:
ftp://sourceware.org/pub/gdb/old-releases/README
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When compiling GDB for target (in my case i386) it links
wrong BFD library from host OS. This prevents GDB from compiling
support for ELF and thus GDB is unusable on target.
More about this issue was already posted at:
http://lists.uclibc.org/pipermail/buildroot/2009-March/026585.html
Fix this issue by forcing ELF support.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Has been marked as broken for more than 1 year, with no indication
that anyone cares, and it needs a bunch of special handling.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 65e99014 (Remove external source toolchain options) removed
external source-based toolchain support, but there was still a check
for it in gdb.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
BR2_VENDOR_GDB_VERSION and VENDOR_GDB_VERSION are no longer settable.
The only user is gdb, and it's totally useless in this case.
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The BR2_VENDOR_SUFFIX and VENDOR_SUFFIX variables are no longer settable.
The only user is gdb, and is totally useless in this case.
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
