nativesdk-libgcc doesn't need a symlink into the target space and if we do this
sstate installation of the recipe can fail depending on whether it races with
the cross-canadian toolchains.
(From OE-Core rev: b2c1e1fe4221862e0dbf5d08960f0d0228e47c72)
(From OE-Core rev: 62012e81c6f7aaad5d9c5e8bec2e2417433572e3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-cross target recipes should not depend on SDK_SYS but started to
after recent changes. Remove the dependency to stop this (its caused
by shared code in do_install). The compiler names contain SDK_SYS
so changes would be correctly handled via other means.
(From OE-Core rev: 2b5761350a074de2e1a6db19621945fba39089fc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Arm is unusual in that we force it to "linux-gnueabi" and "linux" doesn't
build. This was causing problems for multilib configurations which were assuming
"linux" was the default compiler rather than linux-gnueabi.
This change does two things, ensures symlinks are generated for linux-gnueabi
and also adapts the libgcc code to account for the difference on arm.
It still needs to immediately expand/save TARGET_VENDOR but we defer
deciding what TARGET_OS should be until we know TARGET_ARCH (which the
multilib code may change).
[YOCTO #8642]
Note that sanity tests of a 32 bit arm multilib still break due to issues
with the kernel headers on a mixed bit system. This looks to be a general
headers issue for the platform though and a different type of bug.
(From OE-Core rev: bcddc3e7eff138add031bc9c9728be5a42fa62ef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When changing SDKMACHINE, we may encounter an error forcing us to wipe the TMP folder.
Since only SDK_ARCH is captured in the PN of the crosssdk recipes, changes to SDK_OS
result in conflicts. Eventually we hit the error:
ERROR: ...: The recipe <...> is trying to install files into a shared area when those files already exist.
The build has stopped as continuing in this scenario WILL break things
This patchset addresses the problem by SDK_SYS as the recipe name suffix instead
of SDK_ARCH.
[YOCTO #9281]
(From OE-Core rev: d2eccccb70e809d482c493922f23aef4409cfd82)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds the correct support for initfini-array which replaces .init
and .fini with .init-array and .fini-array. There is no appreciable
size difference with this change.
The change is needed since configure will not correctly detect support
when building cross-compilers.
(From OE-Core rev: 9f8a075ab46691534e2b22d0a363b3c847394215)
Signed-off-by: Haitao Huang <haitao.huang@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 "<path>/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 "<path>/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 <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
this in the toolchain, while convenient, actually hides bugs, as a failure to
obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
poison the sysroot -- rather than relying on the default, notice right away if
somoeone isn't obeying the needed flags.
This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
which is what's often seen with external toolchains. This brings us all on the
same page, and makes sure a failure to obey LDFLAGS is seen early.
This is limited to cross, to retain ease of use for SDKs.
(From OE-Core rev: fa436aeb3242cbfdbbe16d448d45bce8eb5b74fd)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
v2: add missing .inc changes
add YP bug # to patch
[Yocto #9632]
not in 6.1.1 so back porting.
(From OE-Core rev: 5d644f5f54097282a77060d78d4f359a8a4c83bb)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's useful to know what the various libraries are that get produced by
gcc-runtime, as well as to have a specific SUMMARY for the recipe.
(From OE-Core rev: b8d5b4107c64784ea8c8f364a84c2bc76cd0b1b0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to use certain features of gcc, you need the corresponding
runtime library. It seems to me that these ought to be installed by
default when installing the compiler since they are required if certain
command line options are used, so add them to RRECOMMENDS. I used
RRECOMMENDS since some of these packages may or may not exist depending
on architecture and build options; additionally it makes it possible to
use BAD_RECOMMENDATIONS if you really want to exclude them.
The impact of this isn't too bad in the context of an image providing
on-target compilation - about a 30MB increase in size for an image
containing gcc and g++.
(From OE-Core rev: 658d9a764e91f394472c9082a3ed3fa7b9b417d2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: b362cf6ef6d7fa22a525cf3e1d17943e897bd8aa)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop patches which has been applied to gcc5 branch
until 5.4 release
(From OE-Core rev: 42487843f846ae61f8bd1b2278d148ff37f0d667)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 85630aa894278e7818c867179dc19ca2fbd994fc)
Signed-off-by: Anuj Mittal <anujx.mittal@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch from mainline gcc 5 branch to fix ICE triggered
when cross-compiling libdrm for nios2 architecture. The same ICE
is fixed in gcc6 already.
(From OE-Core rev: d603a6abf5abff2d1ccee902e0eb9f651aeb121e)
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gperf was being used in a way that generated files don't conform to
the language standard. Backport the fix from upstream.
This is required to build these GCC versions when the host compiler
is GCC 6.
(From OE-Core rev: 42178d1b19f8055434194aa09dcec5006414fab4)
Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gperf was being used in a way that generated files don't conform to
the language standard. Backport the fix from upstream.
This is required to build these GCC versions when the host compiler
is GCC 6.
(From OE-Core rev: 28a53355d7bf490f974500131d7827e3f65674ef)
Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: fcaaabb401fffcda4db9a7d1f927a2a404e4776d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libgcc uses certain options from EXTRA_OECONF as well, curently we are
ignoring them, as a result we do not configure libgcc to match cross gcc
in some cases e.g. ppc/musl should have used 64bit long doubles but
it went for 128-ldbls which is default, works on glibc but not on musl
(From OE-Core rev: d7799a17d5e802db3f8d16bdc824aae81538e675)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libgcc uses certain options from EXTRA_OECONF as well, curently we are
ignoring them, as a result we do not configure libgcc to match cross gcc
in some cases e.g. ppc/musl should have used 64bit long doubles but
it went for 128-ldbls which is default, works on glibc but not on musl
(From OE-Core rev: d774bb2d10f2c05900f87dcc53f073433ca02121)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Explicitly obey it, the way it should, rather than only relying on
--with-linker-hash-style.
(From OE-Core rev: 9095742d1468477baefe69098817f38a8d2dd750)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Small change to python string formatting for error logging.
Previously, tune and availtunes would print out at the end of
the log message. This change allows them to print out in the
correct locations of the error string.
(From OE-Core rev: 65fb2a4af127d32f31fbe696c80de5bafd953200)
Signed-off-by: noel eck <kceleon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we have mips64 port of musl and there is
a name for ldso, backport the fix from upstream
gcc master
(From OE-Core rev: fd37da3a559e0c494c7481849746ec12d492a7b2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For relative path in DWARF, -fdebug-prefix-map could not remap it,
so translate to real path before mapping.
[YOCTO #9305]
(From OE-Core rev: e50d23c30cd8259941b25e336b11cd96e4f6cd31)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We were trying to inject cached configure variables via
EXTRA_OECONF, but that was not working due to the fact
that gcc configure is called recursively via makefiles
and hence these were getting lost.
These backports from master fixes the problem by
defining the options in configure itself
dl_iterate_phdr is provided by musl as well, so lets
not depend on glibc defines like inhibit_libc alone
(From OE-Core rev: b3f80743cd1b9a15a8ee4d20c2a54c2f6cbcd13c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The oe-core may use external toolchain for compiling,
which did not support -ffile-prefix-map.
Since we use -fdebug-prefix-map to do the same thing,
so we could reuse it to replace -ffile-prefix-map.
[YOCTO #7058]
(From OE-Core rev: cec9ee4d32d96e8717f63268a00888260eae1b30)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similar -fdebug-prefix-map, add option -ffile-prefix-map to map one
directory name (old) to another (new) in __FILE__, __BASE_FILE__and
__builtin_FILE ().
With this patch, it fixes build path issue which caused by __FILE__.
We do not need to use relative path to compile any more.
[YOCTO #7058]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
(From OE-Core rev: 5e3dd820df41ab032893497a9ccea2160c07fe66)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LICENSE_${PN} doesn't apply to all gcc-runtime packages. Set LICENSE
instead. Without this fix, gcc-runtime packages such as libstdc++ are
excluded from rootfs for builds which blacklist GPLv3.
(From OE-Core rev: 9406a8ab8fd166b9d90b33b84b6d44f8672ab623)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky jethro has libgomp ( GNU OpenMP ) license marked as GPL-3.0,
where's in fact the correct is GPL-3.0 with GCC Library Runtime Exception
As stated on https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h
header license:
...
Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.
...
(From OE-Core rev: 07db569a91e2aa8456624b340830c0e027cc6ead)
Signed-off-by: Helio Chissini de Castro <helio.castro@bmw-carit.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky jethro has libgomp ( GNU OpenMP ) license marked as GPL-3.0,
where's in fact the correct is GPL-3.0 with GCC Library Runtime Exception
(From OE-Core rev: e24c8be86080bd67ef1c5aa3b9885396dc2774b2)
Signed-off-by: Helio Chissini de Castro <helio.castro@bmw-carit.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
