When using the gcc-sanitizers as part of the SDK on a Linux with a newer
kernel, the ASAN fails randomly. This was seen on Ubuntu 22.04.
This is also described at
https://stackoverflow.com/questions/77894856/possible-bug-in-gcc-sanitizers
Backport the fix from LLVM project, as gcc has not yet backported
anything for the 11 series.
(From OE-Core rev: 7af8e24d6c60a01e398b10a57939947fb156feec)
Signed-off-by: Claus Stovgaard <claus.stovgaard@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Concept of gcc-source prevents cve-check to detect existing
CVE patch file.
So ignore this CVE in all recipes using gcc-source via this
include file.
(From OE-Core rev: 04511734c6dc8c7dda3a943b385cd273d012d8c7)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The runpath in the cc1 binary is:
Library runpath: [$ORIGIN/../../../recipe-sysroot-native/usr/lib:$ORIGIN/../../../recipe-sysroot-native/lib]
This does not match the actual location of the libraries, which would require:
Library runpath: [$ORIGIN/../../recipe-sysroot-native/usr/lib:$ORIGIN/../../recipe-sysroot-native/lib]
Prior to gcc 9.1 the recipe set B explicity with:
B = "${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}"
and this build directory structure matches the runpath in cc1, so there is no issue.
This line was commented out in versions 9.1 through 11.3. The upgrade to 12.1 once
again uncommented this line.
As a result the runpath is incorrect in version 9.1 through 11.3 and cc1 defaults
to using host libraries.
This patch restores setting B as done in master and versions prior to 9.1
(From OE-Core rev: b6f4b3d43a399c2b446754de56ebea35657e13de)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
gcc stable version upgraded from v11.3 to v11.4
For changes in v11.4 see - https://gcc.gnu.org/gcc-11/changes.html
Below is the bug fix list for v11.4
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&order=short_desc%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&resolution=FIXED&target_milestone=11.4
There are a total 115 bugs are fixed in this release, below is the list of bugs fixed excluding the regression fixes.
ID Product Comp Resolution Summary▲
108199 gcc tree-opt FIXE Bitfields, unions and SRA and storage_order_attribute
107801 gcc libstdc+ FIXE Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
108265 gcc libstdc+ FIXE chrono::hh_mm_ss can't be constructed from unsigned durations
104443 gcc libstdc+ FIXE common_iterator<I, S>::operator-> is not correctly implemented
98056 gcc c++ FIXE coroutines: ICE tree check: expected record_type or union_type or qual_union_type, have array_type since r11-2183-g0f66b8486cea8668
107061 gcc target FIXE ENCODEKEY128 clobbers xmm4-xmm6
105433 gcc testsuit FIXE FAIL: gcc.target/i386/iamcu/test_3_element_struct_and_unions.c
105095 gcc testsuit FIXE gcc.dg/vect/complex/fast-math-complex-* tests are not executed
100474 gcc c++ FIXE ICE: in diagnose_trait_expr, at cp/constraint.cc:3706
105854 gcc target FIXE ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: sse2_lshrv1ti3)
104462 gcc target FIXE ICE: in extract_constrain_insn_cached, at recog.cc:2682 with -mavx512fp16 -mno-xsave
106045 gcc libgomp FIXE Incorrect testcase in libgomp.c/target-31.c at -O0
56189 gcc c++ FIXE Infinite recursion with noexcept when instantiating function template
100295 gcc c++ FIXE Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr
100613 gcc jit FIXE libgccjit should produce dylib on macOS
104875 gcc libstdc+ FIXE libstdc++-v3/src/c++11/codecvt.cc:312:24: warning: left shift count >= width of type
107471 gcc libstdc+ FIXE mismatching constraints in common_iterator
105284 gcc libstdc+ FIXE missing syncstream and spanstream forward decl. in <iosfwd>
98821 gcc c++ FIXE modules : c++tools configures with CC but code fragments assume CXX.
109846 gcc fortran FIXE Pointer-valued function reference rejected as actual argument
101324 gcc target FIXE powerpc64le: hashst appears before mflr at -O1 or higher
102479 gcc c++ FIXE segfault when deducing class template arguments for tuple with libc++-14
105128 gcc libstdc+ FIXE source_location compile error for latest clang 15
106183 gcc libstdc+ FIXE std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()
102994 gcc libstdc+ FIXE std::atomic<ptr>::wait is not marked const
105324 gcc libstdc+ FIXE std::from_chars() assertion at floating_from_chars.cc:78 when parsing 1.11111111....
105375 gcc libstdc+ FIXE std::packaged_task has no deduction guide.
104602 gcc libstdc+ FIXE std::source_location::current uses cast from void*
106808 gcc libstdc+ FIXE std::string_view range concept requirement causes compile error with Boost.Filesystem
105725 gcc c++ FIXE [ICE] segfault with `-Wmismatched-tags`
105920 gcc target FIXE __builtin_cpu_supports ("f16c") should check AVX
(From OE-Core rev: 4fd7e5951c42336729f12cde71450ec298f2078b)
Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
After this change in qemu:
c7e89de132
there is no 'max' cpu model on ppc. Drop it to clean up ppc gcc testsuite failures.
In order for this to work we do need to pull in the alternative cpu option from
QEMU_EXTRAOPTIONS on powerpc.
(From OE-Core rev: 3a1b9f300a796e1216d0094043dba7b0f39ec869)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c447f2b21b20fb2b1829d540af2cc0bf8242700c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
By changing the default code generation of GCC we're inadvertently
breaking the GCC test suite, which has ~120K+ more failures when run for
aarch64 compared to x86-64.
This was because the generated code fragments included the BTI
instructions, which the test case wasn't expecting. We can't tell the
tests globally to run without branch protection, as that will break the
tests which also turn it on.
Remove the enabling of branch protection by standard in GCC, we'll
enable it in the tune files instead.
(From OE-Core rev: 759327cf6bd79118bae0c68e63742ae4721471d8)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bb4b9017db6a893ed054a2d2ad4cc671dec09c42)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
some standalone targets e.g. riscv64-elf disable shared linking for
baremetal ELF ABI in ld, therefore lets make it a static library
(From OE-Core rev: 3c6219dfcbcbde314648ba8cc54a90b32ea1c952)
(From OE-Core rev: 4ee9d5839669560ec10f23445fa8bbc03a4c5406)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This function is referencing '${S}/..'.
It uses ${S} only as good known directory path to start
traversing from, and it does not need it to exist or be populated.
If ${S} does not exist yet, the function will fail because
it cannot evaluate path .. from non-existing directory.
Reproducer (verified in master and kirkstone):
bitbake gcc -c deploy_source_date_epoch
bitbake gcc -c cleansstate
rm -rf build/tmp
bitbake gcc -c deploy_source_date_epoch
(From OE-Core rev: 728018bbfe1de53661881a05e0359083ad544f97)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 42661a59cda164b2d236ffc35b4d8cf43312b677)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport fix from master to allow gcc to use proper linker path for
musl [Yocto #14977].
Fixes:
| qemu-arm: Could not open '/lib/ld-musl-armhf.so.1': No such file or directory
(From OE-Core rev: d821a602c56a8d0c8171ee0d2ce31613121be3a6)
Signed-off-by: Pavel Zhukov <pavel@zhukoff.net>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if you switch machines, gcc-source do_deploy_source_date_epoch
would re-run as the stamps are tune specific. This hasn't caused much
of an issue until now, however if we fix the gcc recipes to reuse the
timestamp from this task, it does then create problems.
Copy code from allarch to ensure this task hash doesn't change between
machines/tunes.
(From OE-Core rev: 1511cb3bae2d6e2dad48269108e68967ae302efc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 7e052d03464ba5e880a6c5a0e45ff2f467ef97e8)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst we patch gengtype.cc, we don't patch gengtype-lex.cc which would
be the file which would trigger regeneration of files.
The real bug that was likely the cause for this fix is probably SDE issues
with gcc shared workdir so this code can now be dropped.
(From OE-Core rev: 8a49626bb32b40a2cf97fd8b80564b494ae38698)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 7ab82b5db2a737c2a0266280b15d343a27c0e1d5)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The source date epoch for gcc isn't being transferred from the shared
workdir to the current WORKDIR for the specific recipe. This results in
the clamping code within sstate.bbclass using a value from 2011 which
changes the timestamps of many files. Since this happens part way
through the build, if pieces of gcc haven't built, or build/rebuild
later, we see things rebuilding when they should not and for generated
files, races are possible.
Fix this by copying the SDE from the shared workdir into the recipe
workdir.
[YOCTO #14953]
(From OE-Core rev: 0511f24264bcc27d6b61edd2e16f899c985eb8ad)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit b996293b4c8ab7ff3ed852045d17290df29205df)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix multilib sdk issue where gcc is unable to find linker. Previous
fix was in cdd86896c8d29135f937968e9aa07f919cf543d3 using real-ld
symlink, but that prevented switching between bfd and gold linkers.
Running compiler with debug arguments shows that collect2 tries and
fails to find linker using the multilib triples:
$ $CC -v -Wl,-debug
...
Looking for 'real-ld'
Looking for 'collect-ld'
Looking for 'mips-oemllib32-linux-ld'
Looking for 'mips-oe-linux-mips-oemllib32-linux-ld'
...
collect2 version 12.2.0
ld_file_name = not found
...
collect2: fatal error: cannot find ‘ld’
Using --with-plugin-ld=ld in gcc-cross-canadian builds to set default
linker name for collect2, lets it find the linker correctly:
Looking for 'real-ld'
Looking for 'collect-ld'
Looking for 'ld'
...
collect2 version 12.2.0
ld_file_name = /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/mips-oe-linux/gcc/mips-oe-linux/12.2.0/ld
Swith between bfd and gold linker works as expected now:
$ $CC -v -Wl,-debug -fuse-ld=gold
...
Looking for 'real-ld'
Looking for 'collect-ld'
Looking for 'ld.gold'
...
collect2 version 12.2.0
ld_file_name = /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/i686-oe-linux/gcc/i686-oe-linux/12.2.0/ld.gold
(From OE-Core rev: f4174b3bde5ec91293619fac3258f35153363c51)
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit cf1bb16b7f9f81514feaf1e4ecffd9039387bb89)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit cdd86896c8d29135f937968e9aa07f919cf543d3.
real-ld is always used if that is found, which means you cannot
switch between bfd and gold linkers using -fuse-ld gcc option.
(From OE-Core rev: 3d13ef9e457ad3854c5e9bc37f8ea9a6b0e6c54f)
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 53ae417c63a4a7ff4a729d3653a31cf1c0758f10)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code wasn't changing the linux.h on i686. Make the entry match that
for i586 which was correct.
This fixes problems where the wrong dynamic loader path was used by
nativesdk-gcc on i686 SDK targets by ensuring SYSTEMLIBS_DIR is replaced
by %r in the correct header files.
(From OE-Core rev: 47f6d0da703a9d25fa7dd36793ba332ae8d7ee9e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d30eb681f41bf9e921f7f0d42747fff7a4be9229)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ignore the rmdir cmd if using usrmerge distro feature since the
intention is to delete /lib or /lib64 but not libdir under /usr and
base_libdir = libdir when usrmerge is enabled in distro
(From OE-Core rev: 38fb876253e28577b8fcf4dd47fbb1d0673c6220)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3b7f6b0e0f1f16f89cd924aac001b4f661c145ca)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a dummy shared object therefore reduce dependencies further by
not requiring the C startup files, we wont use this shared library for
anything useful anyway
(From OE-Core rev: 2bc86c029fb82ae572f6a89407ccfe332972568c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes reproducibility issues with multilibs were a different recipe
specific sysroot is used which was leaking into debug symbols in libraries.
(From OE-Core rev: 3bb7abe545be6c92b2bd4f184536b0b0e871aac6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f442edf51e256bd315bd8e4ac4d9fa12b8e9e092)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If gold is enabled as the default linker, it errors trying to link
to our dummy library empty file and this turns off things which should
be present in libstdc++.
For example, _GLIBCXX_HAVE_S_ISREG isn't defined and HAVE_S_ISREG in
libstdc++-v3/config.h isn't set properly.
Instead of just creating an empty file, create an empty elf binary
instead which addresses the issue.
(From OE-Core rev: f842dbc478cb007b5f3e2f016959e2b597a4d0be)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2070bcd10aa3a05c96c8501c6a8c1e129fb1d440)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some tasks may reference ${B} for gcc-source which in general would not exist.
It has dependencies on HOST_SYS and TARGET_SYS which are not appropriate for a
shared recipe like gcc-source. This causes problems for the archiver and
multiconfigs in particlar.
Set B to something else to avoid these task hash issues.
Acked-by: Jose Quaresma <jose.quaresma@foundries.io>
(From OE-Core rev: 7211a6fb51ef0e7f5c919f98a33eaf8094b9c814)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit beb2a76c591e985c6fc7ed473abd1bee27f955a2)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To match the changes to gcc-cross, add a nativesdk-zstd dependency to ensure
our configurations match.
(From OE-Core rev: be70f51806d66daf1994a492dc446062838c0e21)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c145e00710fe557b5a3832fdc556ad53434b3615)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sharing sstate cache binaries between two systems, one with libzstd installed
and the other without, leads to various gcc components being linked against
the system libzstd and failing to run on the system with out it installed.
Make zstd-native from our system available.
(From OE-Core rev: 0efcba381d51a9ab8519c3d50a8b48181a0e38e4)
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2b0a6f03137f24b211c8881cebf65732e550a942)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch is needed in order to support recent glibc (2.34).
libsanitizer/ChangeLog:
PR sanitizer/101749
* sanitizer_common/sanitizer_posix_libcdep.cpp: Prevent
generation of dependency on _cxa_guard for static
initialization.
(From OE-Core rev: c44c4e7fb3c860d9fcb2aada0c9d4acb1e1e8101)
Signed-off-by: Sundeep KOKKONDA <sundeep.kokkonda@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In commit ceda3238 (meta/meta-selftest/meta-skeleton: Update LICENSE
variable to use SPDX license identifiers) all LICENSE variables were
updated to only use SPDX license identifiers.
This does the same for comments and other variables where it is
appropriate to use the official SPDX license identifiers. There are
still references to, e.g., "GPLv3", but they are then typically in
descriptive text where they refer to the license in a generic sense.
(From OE-Core rev: 165759dced7fbe73b1db2ede67047896071dc6d0)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An automated conversion using scripts/contrib/convert-spdx-licenses.py to
convert to use the standard SPDX license identifiers. Two recipes in meta-selftest
were not converted as they're that way specifically for testing. A change in
linux-firmware was also skipped and may need a more manual tweak.
(From OE-Core rev: ceda3238cdbf1beb216ae9ddb242470d5dfc25e0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move cc1plus from gcc to g++ package. Therefor, remove the duplicate
FILES entry from gcc package and keep the entry in g++ package.
(From OE-Core rev: f16c0efdeaca7cd08bd5609141b1094139e746f9)
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The glob to remove the gcc-<version> binary expects a single-digit major
version which is no longer true.
(From OE-Core rev: 30de10cf939cf65c0cab6730a3575bced5c7533a)
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch to gcc to disable use of libstdc++ when configuring the library
during gcc-runtime is old and there are perhaps better ways to do this now.
If removed, most builds still "work" but incorrect values for things like
atomic ops are found during configure. mips64 and ppc fail with on target
simple tests of g++ in testimage.
Instead we can create a dummy libstdc++ which allows the correct configure
test results to be obtained.
Discussed with upstream about the patch are ongoing, if accepted, we can
switch back to the commandline option if it is added in future.
(From OE-Core rev: 34b0edb0d3120c32063ff7e3dd52be20d60401d5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While building GCC it checks whether the include directory exists,
if it doesnt it throws an error and exits:
| The directory that should contain system headers does not exist:
| tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-riscv32/
11.2.0-r0/recipe-sysroot/usr/include/
| make[1]: *** [Makefile:3257: stmp-fixinc] Error 1
Even though for the baremetal toolchain not having this directory
does make sense.
We overcame this by removing the --with-sysroot=/not/exist argument
for baremetal toolchains (via TARGET_OS override), however, the
newlib toolchain does have headers and an includedir, hence by fixing
the baremetal toolchain we broke the newlib one since it uses the same
TARGET_OS as baremetal, causing for example (on newlib):
/sdk/sysroots/x86_64-pokysdk-linux/usr/lib/riscv32-poky-elf/gcc/
riscv32-poky-elf/11.2.0/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
| # include_next <stdint.h>
^~~~~~~~~~
compilation terminated.
By creating a dummy includedir, and removing the previous fix we
allow GCC to be built the same way, unifying the cross compiler
for all targets.
After this fix both TCLIBC=baremetal and TCLIBC=newlib SDKs work
properly.
(From OE-Core rev: 08ff7c87efdf373f1874fcccd9a2a73fc0efef30)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "gcc: Fix compile of gcc plugins" patch had a typo making it a noop.
This was due to a rework to make it specific to the linux64.h header.
(From OE-Core rev: 5f0f00f0988c02d7fe0fa62edf3e4901ce9941a6)
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this, compiling gcc plugins will fail with an error similar to:
[...]
fatal error: ./config/i386/linux64.h: No such file or directory
[...]
In Yocto, we set up compiling gcc-cross out of tree. Which in turn makes
the generated headers end up in B. The tm.h header will include
generated headers that are expected in plugin/include/config/*.
For example, the linux64.h header, when generating gcc-cross for x86-64,
will end up in tm.h header as:
include "./config/i386/linux64.h"
On the other hand, the make rule `install-plugin` in gcc/Makefile.in
will install the linux64.h assuming that it is generated in the sources
directory and because this is not the case in our setup, the Makefile
ends up installing it in plugin_includedir/`basename $$path` which ends
up installing the header in [..]plugin/include as opposed to
[..]plugin/include/config/i386 (as expected by the generator of tm.h).
The included patch modifies the Makefile rule to match the assumption of
gcc-cross being compiled out of tree.
(From OE-Core rev: 92167f8e02bb6fbbe1ee6a6678525a0ae27b00a5)
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch has been accepted upstream
(From OE-Core rev: 4c644708798f258d45dbcfa01909626de32710d4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CVE applies to binutils 2.26 and not to gcc so ignore there.
(From OE-Core rev: fea2726663a3db03170c49fceaffc632c509aeea)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
According to comments on the bug report from gcc developers, we
no longer need to do this post gcc 10. Lets therefore drop the patch.
(From OE-Core rev: 8ddc6f46d40cdcc462de23d1b1218f2ed9fd3d07)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-configure-common.inc already sets --with-abi=64 for our mips64
targets so this patch is no longer needed.
[YOCTO #14639]
(From OE-Core rev: e0010af733825ed1050fd3342cf3ef1c478df1a0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
