openembedded-core.git/meta/recipes-devtools/gcc, branch krogoth

gcc-runtime.inc: Add CPP support for x86-64-x32 tune

2016-11-08T23:03:19+00:00

Using the following setup (as specified in yocto sample code):

MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:libx32"
DEFAULTTUNE_virtclass-multilib-libx32 = "x86-64-x32"

We fail to compile simple CPP programs because CPP cannot
find relevant header files, looking for them in a non-existing place.
To fix this, we create a symlink of the name CPP expects and point it to
the corresponding existing directory.

[YOCTO#10354]
[YOCTO#10380]

(From OE-Core rev: 9f9be229040f4f9a523a1e25afd78d5c3f4efc23)

Signed-off-by: Juro Bystricky 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc-runtime.inc: add CPP support for mips64-n32 tune

2016-11-08T23:03:19+00:00

This patch fixes the problem where the CPP compiler cannot find include files.
The compiler is configured to look for the files in places that do not exist.
When querying the CPP for search paths, we observe messages such as these:

multilib configuration:

MACHINE="qemumips64"
require conf/multilib.conf
MULTILIBS = "multilib:lib64 multilib:lib32"
DEFAULTTUNE = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2"

ignoring nonexistent directory "/sysroots/mips64-n32-poky-linux-gnun32/usr/include/c++/6.2.0/mips64-poky-linux/32

single lib configuration:
MACHINE="qemumips64"
DEFAULTTUNE = "mips64-n32"
ignoring nonexistent directory "/sysroots/mips64-n32-poky-linux-gnun32/usr/include/c++/6.2.0/mips64-poky-linux/

To fix this, create a symlink of the name CPP expects and point it to the corresponding "gnun32" directory.

[YOCTO#10142]

(From OE-Core rev: 55115f90f909d27599c686852e73df321ad1edff)

Signed-off-by: Juro Bystricky 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

libgcc-common.inc: Fix broken symlinks for multilib SDK

2016-11-08T23:03:18+00:00

This patch fixes broken "32" symlinks for multilib settings:

MACHINE = "qemuarm64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and

MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:libx32"
DEFAULTTUNE_virtclass-multilib-libx32 = "x86-64-x32"

[YOCTO#8642]
[YOCTO#10380]

(From OE-Core rev: 2810671a0f96776c135137f27a5ca52194ddd692)

Signed-off-by: Juro Bystricky 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc, qemuppc: Explicitly disable forcing SPE flags for 4.9

2016-09-23T14:24:44+00:00

This ports the missing changes from commit: 7a51776a830167e43cbd185505f62f328704e271
from 5.3 to 4.9 so that qemuppc can be compiled.

Signed-off-by: Pascal Bach 
Signed-off-by: Armin Kuster

gcc-5.3: fix build for gcc-6

2016-07-27T07:33:19+00:00

Backport upstream patch.
It had been applied to 4.9, but not 5.3.

[YOCTO #9897] (Fedora-24)

Signed-off-by: Tim Orling 
Signed-off-by: Armin Kuster

gcc: make sure header path is set correctly

2016-07-06T16:25:21+00:00

We're setting the native header paths in do_configure_prepend,
and don't need to set them again here.

This results in gcc-target not being able to locate the headers
and not being able to detect glibc version, which in turn
results in SSP support not getting detected even though it's available
in libc.

Signed-off-by: Anuj Mittal 
Signed-off-by: Ross Burton 
(cherry picked from commit 85630aa894278e7818c867179dc19ca2fbd994fc)
Signed-off-by: Anuj Mittal 
Signed-off-by: Armin Kuster 
Signed-off-by: Richard Purdie

gcc-5: Fix hang with mmusl option on cmdline

2016-07-06T16:24:59+00:00

When using -m32 -mmusl options in this order, gcc hangs
in parsing the options decode_cmdline_options_to_array()
the reason is that we have broken the link when adding
mmusl options, the order of specifying libc was not kept
in order as a result it was unable to contruct the array
correctly and ended in parse hang.

We fix the options to specify the order properly.

Signed-off-by: Khem Raj 
Signed-off-by: Armin Kuster 
Signed-off-by: Richard Purdie

gcc-runtime, libgcc: Symlink c++ header and startup files in target_triplet for SDK use

2016-06-29T18:34:45+00:00

We build SDKs such that gcc-cross-candian is built for only one
target *-*-linux and then use -muclibc or -mmusl to let it compile
code for other libc variants. This works fine when libc = glibc
however it does not work for c++ programs when libc != glibc since
there are c++ headers installed under ${includedir}/c++/${BINV}/${TARGET_SYS}
which is fine when gcc-runtime and gcc-cross-candian uses same --target options
gxx includedir searches in right triplet, but it fails with musl/uclibc
since gcc will look for glibc based triplet but gcc-runtime will install
them under musl/uclibc triplet.

This patch symlinks the musl/uclibc triplet to glibc triplet when libc != glibc

This fixes SDKs for musl/uclibc

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc-sanitizers: Depend on target gcc

2016-06-29T18:33:07+00:00

Without this the target gcc might not be in the sysroot
leading to configure failure.

(From OE-Core rev: 329c532db4b2124fa3f4b3ab8c4c6d6c93ca7c2f)

Signed-off-by: Jussi Kukkonen 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc-4.9: fix build with gcc 6

2016-05-18T19:50:07+00:00

Building gcc-cross 4.9.3 with gcc 6 fails with the following error:

error: 'const char* libc_name_p(const char*, unsigned int)' redeclared inline with 'gnu_inline' attribute

This is a backport of the upstream fix.

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Richard Purdie