This patch was mentioned upstream a long time ago:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47256
Changes from gcc 10 onward mean it is no longer needed as mentioned in the
above bug report. Drop the patch.
(From OE-Core rev: 6fca075a8d87d033359f81d476c8506df66ad53d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since commit 044fb04d in bitbake (fetch2: Allow whitespace only mirror
entries) there is no need to separate the entries in MIRRORS with "\n".
(From OE-Core rev: 5374c45725ef5796a563c0665cde0fc05cecd856)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The libgfortran configure sets FC to be $GFORTRAN. We did used to patch
that out but rather than carry a patch to gcc, just set GFORTRAN as
needed.
(From OE-Core rev: 4ec096a9ce8a49b631efc50e7d95ff653d4c4374)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As far as I can see, when building libgfortran we don't set GFORTRAN so this
patch does nothing any more. The fortran build and gcc recipes have changed
massively since gcc 4.2.2 so I think this patch is simply obsolete.
I did test building libgfortran with and without this patch and there was
no difference, the correct fortran compiler is found. If it were an issue
we should just set GFORTRAN correctly. Therefore drop the patch.
(From OE-Core rev: bc5209aa5f07cea00416852532b90aba044defd5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch has headers as if it were submitted upstream but I can't find any
record of it. I did try tests with it removed, building the referenced testsuite
files with -Werror and it all works just fine with no warnings or errors (tested
on MACHINE=qemux86). I suspect this was fixed in gcc itself in other ways.
As such I think this patch isn't needed and suggest we drop it. If there is
a reason it is needed, please report along with an example of how to reproduce
issues.
(From OE-Core rev: d83e12da74b853ae33045e5c216c90c78a19f54d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I took 5 of our patches and submitted to upstream gcc. This highlighted that
patches 0026 and 0018 should be merged together and some tweaks were made to
try and make it acceptable to upstream. The other patches have their headers
updated to match what was submitted.
The libstdc++ option patch was also cleaned up ready for upstream as the
documentation wasn't quite right.
The CXXFLAGS_FOR_BUILD piece of 0026 is separated out into a new patch which
can be submitted separately to upstream.
Two of the patches have been merged, status updated accordinly.
(From OE-Core rev: df9b8ec56ff29f14feb1fde6acbdf9c4667430cf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch looks obsolete because it looks like part of an upstream
backport on a very old gcc version (4.3.3) and looks incomplete. The
diff also has little context making it likely to be a rebase error.
Builds seem find without it so drop it.
(From OE-Core rev: 7bc50b6de2df8555f7e19ff37f103bbe65955f72)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we now have recipe specific sysroots we no longer need this patch
to avoid the dtrace headers affecting the build of gcc-runtime. Drop
the patch.
(From OE-Core rev: 9aa8ff2dbbbf38cb0c87efd32db64b8ddf485ddf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SYSTEMLIBS_DIR change was spread over three patches, merge these
together since there is no value in having them separate.
(From OE-Core rev: dd1fef1b520efaac6a21f26332c25bdcc0110c12)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Alongside GLIBC and UCLIBC, also relocate the musl loader.
(From OE-Core rev: 24c4e01892df1510e5ba64b89a0060f62f2384e6)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In newer gcc versions the headers changed locations and our multiconfig
and nativesdk tweaks to loader paths wasn't working. The broke
buildtools-extended-tarball, particularly on arm. Update to fix this.
Ultimately we should dump the gcc specs and check for hardcoded paths.
This isn't possible quite yet as this patch doesn't fix the musl ones
as we don't use that in mutlilib or nativesdk scenarios at present.
(From OE-Core rev: 4ed6505a18ac76c0aa148deabb143214ac0c4552)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport ustream gcc patch that enables -fdebug-prefix-map to cover
additional cases with LTO enabled to make LTO builds more reproducible.
[YOCTO #14481]
(From OE-Core rev: 8923253b9bc91b14b474abc4923ca916fb8a12ec)
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Those were missed in previous rounds of automated and manual conversion.
(From OE-Core rev: 22f9c7268b542baf6cd8aa0e34c8fb7aa1579e08)
Signed-off-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update gcc, drop patches that have been merged upstream
(From OE-Core rev: 8979de58dc49fb4f8bc55743a1a4bf613c675a4e)
Signed-off-by: Bernhard Rosenkränzer <bero@lindev.ch>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
W/o that hack target GCC assume existence of per-mcpu folders,
which are missing.
In particular G++ failed to find "bits/c++config.h":
------------------>8------------------
root@hsdk:~# cat test.cc
#include <cstdlib>
int myfunc(void)
{
}
root@hsdk:~# g++ -c test.cc -v
Using built-in specs.
COLLECT_GCC=g++
Target: arc-oe-linux
Configured with: ../../../../../../work-shared/gcc-11.1.0-r0/gcc-11.1.0/configure --build=x86_64-linux --host=arc-oe-linux --target=arc-oe-linux --prefix=/usr --exec_prefix=/usr -x
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.1 20210523 (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-shared-libgcc' '-mcpu=hs38_linux'
/usr/libexec/gcc/arc-oe-linux/11.1.1/cc1plus -quiet -v -imultilib hs38_linux -D_GNU_SOURCE test.cc -quiet -dumpbase test.cc -dumpbase-ext .cc -mcpu=hs38_linux -version -o /tmp/ccs
GNU C++17 (GCC) version 11.1.1 20210523 (arc-oe-linux)
compiled by GNU C version 11.1.1 20210523, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129242
ignoring nonexistent directory "/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux/hs38_linux"
ignoring nonexistent directory "/usr/lib/arc-oe-linux/11.1.1/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../arc-oe-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1
/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/backward
/usr/lib/gcc/arc-oe-linux/11.1.1/include
/usr/lib/gcc/arc-oe-linux/11.1.1/include-fixed
/usr/include
End of search list.
GNU C++17 (GCC) version 11.1.1 20210523 (arc-oe-linux)
compiled by GNU C version 11.1.1 20210523, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129242
Compiler executable checksum: 6df2f07a822bfbbb80a61414b712b75d
In file included from test.cc:1:
/usr/include/c++/11.1.1/cstdlib:41:10: fatal error: bits/c++config.h: No such file or directory
41 | #include <bits/c++config.h>
| ^~~~~~~~~~~~~~~~~~
compilation terminated.
------------------>8------------------
Note "ignoring nonexistent directory "/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux/hs38_linux"
message which is being used by GCC due to the fact of implicit "-mcpu=hs38_linux".
In fact this header "bits/c++config.h" is located in "/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux"
on target.
(From OE-Core rev: fbdc4422361a520af458468d836a8e4159dc22d6)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A change in the gcc-11 branch broke installation of the GDB helper on
bare-metal targets without a shared libstdc++.so. This now fixed
upstream so replacce the revert with a backport of the patch.
(From OE-Core rev: 5137ca0a295c3ab8d938d67ea292300bb2cbab93)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pass --enable-standard-branch-protection. This is an aarch64-specific
option (currently) which does nothing on other targets. On aarch64 this
generates code uses BTI/PAC instructions to mitigate Return Orientated
Programming attacks. This approach is backwards compatible and the code
size/performance impact is typically negliable.
More details can be found at
https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
(From OE-Core rev: 84e6064cde02b463066d7b63fcf8baf392491327)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit dbb87d in the GCC 11 branch was intended to make the installation of
this Python module more robust, but for unknown reasons the library_name
in libstdc++.la in baremetal builds (for example, Zephyr) is unset, so the
module is just installed as "-gdb.py".
This may be a GCC bug, or a bug in our build. Until that is resolved,
revert the commit to fix the packaging.
(From OE-Core rev: 61947fc024bf18b42547d2ea4cad90184132994d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When -fuse-ld gcc option is used, missing ld.bfd or ld.gold symlinks
can lead to linker error:
collect2: fatal error: cannot find 'ld'
(From OE-Core rev: 9ec1cd0a1e4cc2740be37585231279adf91c47d7)
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
musl includes were not using the relocatable prefix like glibc
counterpart, this will mean that musl SDKs will behave better and find
the headers in right install directories
(From OE-Core rev: 8cb141306f13fa6e25c89c104af9ad0af431eb5d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Musl has different search order and therefore injects it
via INCLUDE_DEFAULTS and does not use the defaults from
gcc/cppdefaults.h, this ensures that same fix is extended
to musl configs too where it can search for compiler headers
It will fix builds with musl where omp.h is not found because
it is in gcc includes path on target ( not cross ) sysroot
(From OE-Core rev: 3ff688ca02dcc4c0187d1ddc214ec0c74b4e73f1)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* introduced with gcc-11, other hwasan files were already packaged in:
3df4a25465 gcc-sanitizers: Package up hwasan files
but static library was still triggering installed-vs-shipped
(From OE-Core rev: 49aec04aa8ac98545b48c41382ebf1a1c3be1118)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libstdc++ uses assertion macros which use __FILE__ macros and
if (__builtin_expect(!bool(_Condition), false)) \
std::__replacement_assert(__FILE__, __LINE__, __PRETTY_FUNCTION__, \
#_Condition)
This ends up using absolute paths into build tree for the cases where
the charconv header is used, therefore replace the file prefix paths
with on-target paths to make them build dir independent
(From OE-Core rev: 972c50d6e46ee9dfba8b8ea3867ebdbf24001e6e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps binutils provided tools ar/ranlib/nm to find the LTO linker
plugin automatically as well which makes it equivalent to gcc-ar/gcc-nm/gcc-ranlib
(From OE-Core rev: 7d8d0b90bea7ea01e1e9ab0ff98f22431f68a506)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will ensure that ar/ranlib/nm can load the lto linker plugin like
gcc-ar, gcc-nm, gcc-ranlib does, this will let the behaviour match
between gcc wrappers for these tools, this should help LTO builds for
packages
(From OE-Core rev: d6658505089234476c1b35fc08fef1eb4f121e85)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This directory is scanned by binutils provided ar,ranlib,nm for plugins
that it can load automatically, putting liblto_plugin.so in their means
we do not need gcc-ar, gcc-nm, gcc-ranlib particularly as normal
ar/ranlib/nm tools will work equally well as they can now use this
linker plugin by default
This also mean we can revert back to using ar/ranlib/nm as default
providers for AR/NM/RANLIB on target
(From OE-Core rev: 5aae5812223792d5e5bd57e024de50fbcd1e6da5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current definition of SLIB is actually equal to S but is hardcoded, this
means when we have altered location of S, then the regexp for
DEBUG_PREFIX_MAP will not be effective, which could result in S being
emitted into debug_line sections. Simplify the maps to use S variable
instead of SLIB
Secondly, rename SLIB_NEW to REL_S to make it more appropritate to what
it represents
(From OE-Core rev: 2c8e130adb5d4d55ba732a042ec157498460ee29)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes an error in do_patch when using "PATCHTOOL = "patch""
error message:
checking file gcc/configure.ac Hunk #1 FAILED at 6602.
(From OE-Core rev: f75a1eddc7c01d9a83d0a1114fc0d6aaa79d8806)
Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building the cross GCC, configure it so that including the host
system include directories is fatal, not just a warning.
(From OE-Core rev: d039d6fbfc9076f081173f6e5cc63c56fe3a5adb)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extend --enable-poison-system-directories so that it can be an error
instead of a warning by default.
(From OE-Core rev: 1fcaa5f452b2c6b93a6f3dfd57f894cbef5e3379)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In e9e5744ba8b0d43c8b874d365f83071ce20bf0a1, Khem Raj wrote:
> OE does not use the traditional /usr/lib/gcc prefix to store
> gcc-runtime it basically is moved into libdir, however some newer
> files were installed by newer versions of gcc especially libgomp (
> omp.h openacc.h ) into gcclibdir, so we have content in both
> directories, this confuses other tools which are trying to guess the
> gcc installation and its runtime location, since now we have two
> directories, the tools either choose one or other and we get
> inconsistent behavior, e.g. clang for aarch64 uses /usr/lib but same
> clang for riscv64 chose /usr/lib/gcc
> This change ensures that OE ends up with single valid location for gcc
> runtime files
I think that the same thing needs to happen in gcc-sanitizers.inc,
otherwise I get errors like:
| .../recipe-sysroot/usr/include/gpg-error-64.h:884:11: fatal error: sanitizer/lsan_interface.h: No such file or directory
when attempting to compile with sanitizers enabled.
FILES_${PN} needs updating to match too.
(From OE-Core rev: 862b4fac3ee7d951758c8c93462331ad52bf0190)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Cc: Khem Raj <raj.khem@gmail.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added HOMEPAGE and DESCRIPTION for recipes with missing decriptions or homepage
[YOCTO #13471]
(From OE-Core rev: bb05814335e7101bfd8df0a11dc18a044e867bed)
Signed-off-by: Dorinda Bassey <dorindabassey@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream has merged a change to handle detection of target overrides so
that they are only applied as required. Backport this patch from
upstream and remove the OE specific patch.
(From OE-Core rev: d430f425e1a5725e93833a652e5c6988576f7347)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compiling gcc-runtime for i686 libatomic, libgomp and libitm are
compiled with additional '-march' and '-mtune' overrides. This typically
does not cause build errors (e.g. core2-32 tune), and results in less
optimally tuned outputs. However with specific TUNE_CCARGS (e.g. has
'-mfpmath=sse' but not '-msse*'), the build errors with conflicting
'-mfpmath' options.
This is caused by gcc-runtime specific configure scripts and Makefile
options that override by adding additional '-march'/'-mtune' args. OE
builds gcc-runtime differently to other build systems, and provides
target specific arch/tune options directly. As such, this change adds a
patch for gcc to remove the specific cases where the args are added.
(From OE-Core rev: d39b686cc5fcc89405ffeb560ea64b5d305b0608)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PREFIXVAR is defined in cppdefaults.c as well which shows up as error
when LTO is enabled to build gcc, therefore rename the one instance to PREFIXVAR1
(From OE-Core rev: 984da023a595a10ae62d4fc2a1f2fe96c4701223)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
