When compiling glibc 2.16 and gcc 4.7.4 with CT_ARCH_FLOAT="hard",
I end up in a dynamic linker called /lib/ld-linux-armhf.so.3, but
gcc compiles the binaries with an ELF interpreter /lib/ld-linux.so.3.
That doesn't work.
This patch (which is included in recent gcc version and also is included
in Linaro 4.7 versions) fixes the problem. I just stripped the ChangeLog
diff from the original commit.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
It applies manually with fuzz 2, but ct-ng does not accept any fuxx at all.
So, re-diff the patch so it applies cleanly.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Fix the problem with parallel build on gcc 4.8.0, 4.8.1 and 4.8.2
See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57683
and
http://gcc.gnu.org/viewcvs?rev=205189&root=gcc&view=rev
Log:
2013-11-21 Zhenqiang Chen <zhenqiang.chen@linaro.org>
PR bootstrap/57683
Backport from mainline: r197467 and r198999.
2013-04-03 Jeff Law <law@redhat.com>
* Makefile.in (lra-constraints.o): Depend on $(OPTABS_H).
(lra-eliminations.o): Likewise.
2013-05-16 Jeff Law <law@redhat.com>
* Makefile.in (tree-switch-conversion.o): Depend on $(OPTABS_H).
Signed-off-by: "Daniel Zimmermann" <netzimme@gmail.com>
Message-Id: <66398633eea949023e0d.1385290839@haus-VirtualBox>
Patchwork-Id: 293742
This patch fixes compilation of gcc when C++ is enabled and MMX is
available, but not SSE/SSE2/AVX.
Signed-off-by: Richard Braun <rbraun@sceen.net>
Message-Id: <20121126105642.GA12098@mail.sceen.net>
Patchwork-Id: 201648
Remove the sparc part, as it touches code that does not exist in
those versions of gcc (it was added at 4.6.2).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
CC: Florian Fainelli <f.fainelli@gmail.com>
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54369 for more information
This bug has a serious effect on Linux/MIPS and SPARC kernel builds.
Add the fix for these versions of gcc: 4.6.0, 4.6.2, 4.6.3, and 4.7.0.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Building uClibc with libubacktrace requires libgcc_eh.a to be available,
but gcc does not build it unless it is configured to generate shared libs.
However, libgcc_eh.a does not *require* shared libs support, as it is a
static library.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building ecjx, the compiler for the build system must
be used, not for the compiler for the host system.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Fix building libffi on OABI.
Although it has been marked as 4.3-only, it is stil not fixed,
and also applies to 4.4.x
See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42289
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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
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 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(+)
[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(+)
