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.
