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>
* Add a new gdb version for AVR32 in Config.in
* Use a special mirror for this gdb version in gdb.mk
* Do not try to apply patches when the patch directory does not exist
in gdb.mk
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We have been passing -q to ./configure when using 'make -s' for
packages using Makefile.autotools.in for some time. Do the same
for packages using autotools, but not using the
Makefile.autotools.in infrastructure, taking care to not do it
for packages with hand written configure scripts.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
To reflect the new output directory hierachy rename the Makefile variable
TOOL_BUILD_DIR to TOOLCHAIN_DIR.
Signed-off-by: Michael Roth <mroth@nessie.de>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The GNU_TARGET_NAME symlink and target_utils location were not correctly
adjusted to match the move of the toolchain to $(STAGING_DIR)/usr,
creating dangling symlinks.
git-svn (and git) doesn't handle empty directories, so add .empty files
to those dirs like elsewhere in buildroot.
Those empty directories are normally not a big deal, but the recent changes
to u-boot broke the build.
We used to use different gdb configs for internal and external toolchains
because mconf won't source the same file twice. This works, but is kind of
sub optimal, as people forget to keep them in sync.
Fix it to use the same file for both situations by shuffling around the
config options a bit. Should work identical to before (except for the newer
gdb versions available for ext).
