On a Fedora 12 x86_64 build/host box, this file was complaining about
PTRACE_PEEKTEXT being undefined. Adding in the "ptrace.h" include
fixed it.
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
The added code should be conditinal to the target system
being !MIPS, but is based on the host system being !MIPS.
This is plain wrong, and had not been noticed until now
as I never used those binutils versions on MIPS.
See:
http://sourceware.org/ml/crossgcc/2010-08/msg00192.html
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Without this patch, crosstool-ng-built glibc-2.9 prevents
debugging any exeutable with gdb.
gdb says:
[Thread debugging using libthread_db enabled]
find_new_threads_callback: cannot get thread info: generic error
See also https://bugzilla.redhat.com/show_bug.cgi?id=487212
for a discussion of the bug and the solution.
This is the change introduced by revision 734 of MPC repository.
Author: Paul Zimmermann <Paul.Zimmermann@loria.fr>
Revision log: [acos.c] fixed problem with GMP_RNDA (should be MPFR_RNDA, and code was wrong)
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Add several development libraries to the build of the mingw cross-compiler
to be used on target
Libraries:
PDCurses (port of the ncurses library)
GnuRX (the regex library)
DirectX
OpenGL
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: don't show DX and RX versions if disabled]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
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>
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>
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.
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
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.
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.
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.
The generated libtool for building libstdc++ adds the -nostdlib option to the
g++ command for linking but doesn't add -lgcc. This causes a "hidden symbol"
error when linking against the libstdc++ shared object. This patch adds gcc
to the list of libraries linked against when linking libstdc++.
/trunk/patches/gcc/4.2.1/300-libstdc++-nostdlib-linking.patch | 21 21 0 0 +++++++++++++++++
1 file changed, 21 insertions(+)
I'm using CTNG for some embedded Linux work on an ARM926ej-s, and when
updating to glibc 2_9, I needed to use the attached patch to get it to
build cleanly.
/trunk/patches/glibc/ports-2_9/100-arm_linux_tls.patch | 14 14 0 0 ++++++++++++++
1 file changed, 14 insertions(+)
[This]patch is a bit more involved. The patch addresses a gcc
regression in the 4.3 series (specifically this patch is against 4.3.2
which does *not* have a lot of other issues which affect kernel building)
GCC bug tracker has this issue as
#38453http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453#32044http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
comment 65 of #32044 has the fix being applied to gcc trunk as revision #142719
The attached patch is a backport to gcc 4.3.2 which allows this
version to be used to generate correct output for various ARM kernel
build (and indeed is teh correct answer in general).
/trunk/patches/gcc/4.3.2/360-fix-expensive-optimize.patch | 207 207 0 0 +++++++++++++++++++++
1 file changed, 207 insertions(+)
[This] patch is a simple one for strace 4.5.17 .They altered the
exported kernel headers post 2.6.26 and removed a header. This patch
is a backport from the strace revision system. This allows strace to
be built with 2.6.27 and later kernel versions
/trunk/patches/strace/4.5.17/190-dirent-include.patch | 33 33 0 0 +++++++++++++++++++++++++
1 file changed, 33 insertions(+)
