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(+)
