Age | Commit message (Collapse) | Author | Files | Lines |
|
Adds patch for GDB v6.8, v7.0, v7.0.1 to fix canadian
cross building of GDB for powerpc.
See original patch information here:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=9638
The patch is not required for GDB v7.1 (fixed).
Tested in canadian combination using mingw32 and powerpc toolchains.
Tested to not affect normal cross building of GDB for powerpc target.
Signed-off-by: Martin Lund <mgl@doredevelopment.dk>
|
|
The configure script correctly detects libsupc++ and libiberty, but in
the linker stage it tries to link in both libraries without taking care
of the test result.
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
[yann.morin.1998@anciens.enib.fr: rework patch depth to be -p1]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
Backported from:
http://sourceware.org/ml/libc-alpha/2009-09/msg00024.html
Thanks to Khem RAJ for pointing to this fix:
http://sourceware.org/ml/crossgcc/2010-05/msg00033.html
|
|
Add 4.4.4 and forward-port patchset from 4.4.3
|
|
For uClibc, the name of the Blackfin architecture is 'bfin'. Actually,
the naming of the architecture is quite messy: for toolchain tuples
and uClibc, it's bfin, but for the kernel, it's blackfin. We've
arbitraly choosen to name it "blackfin" in Crosstool-NG.
Add Blackfin-related uClibc patch to fix a build failure related to
fork() being used in unistd/daemon.c.
Yann E. MORIN:
Apply the patch to the kernel/linux build script to use 'linux'
in the noMMU tuples. See:
http://sourceware.org/ml/crossgcc/2010-04/msg00010.html
|
|
Disable unaligned access at least for mcpu32, m68010 and m68020.
These processors certainly do not like unaligned accesses.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
|
|
In the Blackfin case (untested until now), this patch was lacking a
leading / at the end of a comment.
|
|
|
|
GMP : 4.3.2, 5.0.1*
CLooG/PPL: 0.15.8 0.15.9
libelf : 0.8.13
*: patch series added
|
|
As discussed there: http://sourceware.org/bugzilla/show_bug.cgi?id=9678#c4
Reported by: Sasha Sirotkin <buildroot@browserseal.com>
|
|
Reported by: Thomas Petazzoni
http://sourceware.org/ml/crossgcc/2010-03/msg00057.html
Discussions:
http://lists.uclibc.org/pipermail/uclibc/2010-March/043697.html
http://lists.uclibc.org/pipermail/buildroot/2010-March/032790.html
http://ibot.rikers.org/%23uclibc/20100316.html.gz
(search for "copysignl", by kos_tom, blindvt and y_morin)
|
|
Older glibces were not ready to handle binutils >=2.20.
Fix that, and the forseeable future.
|
|
Commit in upstream buildroot:
http://git.buildroot.org/buildroot/commit/?id=43ffd946ad569f3a1d0662de221cd4cb65bdc8e6
Everything on the 0_9_30 branch since the release (0.9.30.3 to be)
|
|
|
|
gcc-4.3.0 never got !EXPERIMENTAL, and no one either confirmed nor complained.
|
|
|
|
|
|
Some patches from 0.9.30.1 now applied upstream. The reminder have
been only slightly modified to apply cleanly to the new base.
Signed-off-by: Joachim Nilsson <jocke@vmlinux.org>
|
|
Pack netinet structs to be possible to use for creating
IP frames on big-endian targets.
Signed-off-by: Joachim Nilsson <jocke@vmlinux.org>
[yann.morin.1998@anciens.enib.fr: removed getline patch, already in]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
This is a set of patches for binutils-2.20 that have been "ported", or rather
shamelessly stolen, from the OpenEmbedded project:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/binutils/binutils-2.20
Tried and tested on Arm (big-endian Xscale, and little-endian i.MX27) with GCC 4.4.2
Signed-off-by: Joachim Nilsson <jocke@vmlinux.org>
|
|
|
|
Patch from Ralf Wildenhues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818#c5
Testing thanks to Joachim Nilsson:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818#c7
|
|
On x86, gcc-4.4.x breaks when building for target armeb.
It is still required to configure with: --disable-shared
Note: if building on an x86_64, there is no need to pass --disable-shared
|
|
From this version of ltrace the maintainer has removed support for
GNU Autotools, so the patch sets needed to be reworked.
Included is the latest Debian patch, by the Debian ltrace maintainer
Juan Cespedes <cespedes@debian.org>, the OpenEmbedded patches for cross
compiling, by Khem Raj <raj.khem@gmail.com> and a further set of patches
by Joachim Nilsson <jocke@vmlinux.org> for crosstool-NG.
|
|
As reported by Joachim Nilsson <jocke@vmlinux.org>
in: http://sourceware.org/ml/crossgcc/2010-01/msg00005.html
It seems I need to add the 4.3.4/290-index_macro.patch to the GCC 4.4.x
series as well. I immediately trigger the following libstdc++ bug for
4.4.2 with a uClibc .config which has UCLIBC_SUSV3_LEGACY_MACROS set[1].
http://lists.busybox.net/pipermail/uclibc/2006-April/035991.html
|
|
Here's a couple of patches to get strace 4.5.19 to configure and build
properly with the latest kernel headers. Not pretty, but hopefully
enough while we wait for 4.5.20 to be released.
With the current strace-4.5.19 patches I failed to get the configure
script running even on my host environment. Also, when cross building
the configure script needs to look for the proper system headers to be
able to properly set HAVE_LINUX_NETLINK_H. Otherwise you get:
[EXTRA] Building strace
[ERROR] /home/jocke/x-tools/targets/src/strace-4.5.19/net.c:976:
error: field 'nl' has incomplete type
[ERROR] make[2]: *** [net.o] Error 1
[ERROR] make[1]: *** [all] Error 2
The fix was simple, backport a change set from the git[1] tree and run
autoreconf to update the configure script.
[1] - http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commit;h=f0df31e71a58c6e79ba77c1a9d84b2f38d44bec7
|
|
According to: http://sourceware.org/ml/crossgcc/2009-11/msg00109.html
update the patchset for correct Alpha build.
|
|
the configure script had to be modified to accept as/ld at versions greater
than 2.19
Signed-off-by: Frederic Roussel <fr.frasc@gmail.com>
|
|
|
|
Woo... It seems the glibc guys finally decided that tarballs
were not deprecated, in fact.
The patchset was vampirised from Gentoo (kudos, guys!), and
applies to glibc+ports, so that's why it's been added as a
patchset against ports, not against glibc.
|
|
Fix filenames in patch files for binutils-2.20.
Some patch files were only usable with patch argument '-p0'.
Fix the diff context to match 2.20 release.
Signed-off-by: Frederic Roussel <fr.frasc@gmail.com>
|
|
|
|
While trying to build a toolchain with ct-ng 1.5.0,
arm-unknown-linux-uclibcgnueabi target,
I get the following error:
[INFO ] Installing C library headers
[EXTRA] Copying sources to build dir
[EXTRA] Applying configuration
[EXTRA] Building headers
[EXTRA] Installing headers
[ERROR] extra/scripts/unifdef.c:209: error: conflicting types for 'getline'
[ERROR] make[2]: *** [extra/scripts/unifdef] Error 1
[ERROR] Build failed in step 'Installing C library headers'
The following patch solves the problem.
(It's a backport of this uClibc commit:
http://git.uclibc.org/uClibc/commit/?id=49e81cada73616864b9b31df0aeb6961c30f5a6e
)
[--SNIP from another mail--]
AFAIK this is a problem since glibc 2.10.
|
|
Also add patchset vampirised from Gentoo.
|
|
Also propagate the patchset from 4.5.18 to 4.5.19.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For ARM EABI hosts (ct-ng's target), the tupple ends in 'gnueabi'
For uClibc-based toolchains, the tuple ends in '-uclibc.*'
Make ltrace recognise those tuples as being the same as 'linux-gnu'
|
|
As pointed out by Martin GUY, gcc incorrectly generates armv5t
instrcutions for EABI, even for cores that are an armv4t.
The new patch (for the 4.3 series) fixes the problem by downgrading
the default CPU for EABI to being an armv4t core.
|
|
|
|
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
When compiling some C++ code, GCC 4.3.x fails with an internal
compiler error. The bug report is available at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436. The included patch
is the one that has been merged in the trunk of gcc.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
The tmul test uses a compiled-in input file in $(srcdir).
The problem is that the Makefile passes it unquoted. The C code
tries to stringify it using clever macros, which may *usually* work.
In my case the source directory was named:
.../toolchain-powerpc-e500v2-linux-gnuspe-1.0-2.fc10/.../tests
And guess what? During testing I found out the program fails because
it tries to open:
.../toolchain-powerpc-e500v2-1-gnuspe-1.0-2.fc10/.../tests
Yes, CPP tokenized the macro before stringifying it and not surprisingly
the 'linux' part was converted to 1.
[on Fedora-10: cpp (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)]
So the attached patch simplify the macros and pass the path as string
from the Makefile.
|
|
Add 4.3.0 and 4.3.1.
|
|
Add libelf 0.8.11, propagate patchset from 0.8.10.
|