summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc
Commit message (Collapse)AuthorAgeFilesLines
* meta: remove consecutive blank linesAlexander Kanavin14 days6-9/+0
| | | | | | | | | | | | | | | | | Some of them were introduced by mass-removal of S = WORKDIR/git assignments; rather than try to fix up (or redo) just these, I've run this sed command over the whole tree: sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name *.bb -o -name *.inc` The rationale is that more than one empty line is wasting vertical screen space, and does nothing for readability. (From OE-Core rev: cedc4ff7c9bcfb22a20e43e47f9759f4007a4f1a) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc/clang: set S to be in UNPACKDIRAlexander Kanavin14 days3-4/+6
| | | | | | | | | | | | This and some further commits allows removing the 'backwards compatibility magic' in do_unpack that moves unpacked sources to where S is set to. (From OE-Core rev: 6b2f14cd2d110113f1065bdc818ec4e9dbd4b054) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Turn FORTRAN into a weak assignmentKhem Raj2025-06-092-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This ensures that it can be turned on from a distro layer config metadata e.g. local.conf without forcing overrides currently we have do something like FORTRAN:forcevariable = ",fortran" RUNTIMETARGET:append:pn-gcc-runtime = " libquadmath " TOOLCHAIN_TARGET_TASK:append = " gfortran" to enabled fortran support from distro conf file. After this change we can do it with FORTRAN = ",fortran" RUNTIMETARGET:append:pn-gcc-runtime = " libquadmath " TOOLCHAIN_TARGET_TASK:append = " gfortran" (From OE-Core rev: 50abae55eda0115d073bbc6552f2fcb4ecbb7949) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix riscv32 multilib issues in non-multilib toolchainKhem Raj2025-05-292-1/+3
| | | | | | | | | | | | GCC RISC-V multilib does not map to OE's mutlilib concept extend the fix [1] done for RISCV64 to RISCV32 as well [1] https://git.openembedded.org/openembedded-core/commit/?id=3081f62c18fcee642ab43efa717c8f71d51ae587 (From OE-Core rev: c9b310ad363a41dfa515308780a3f8fde67d8fdc) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: fix incorrect preprocessor line numbers in large filesYash Shinde2025-05-272-0/+476
| | | | | | | | | | | | | | | | Resolve static assertion failures caused by incorrect line numbers after #include directives, introduced by the backport of PR108900 to GCC. Update line map handling to correctly compute locations in large files, including fixes for both LC_ENTER and LC_LEAVE to ensure accurate line number resolution in rare edge cases. https://gcc.gnu.org/cgit/gcc/commit/?id=edf745dc519ddbfef127e2789bf11bfbacd300b7 (From OE-Core rev: 3b22793f4bdee25b87dda03574f65e3441d230ba) Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix wrong code generation in atomic intrinsics for armJeroen Hofstee2025-05-272-0/+96
| | | | | | | | | | | | | This is seen with QT code Error: ARM register expected -- `ldrex r1,[s16]' (From OE-Core rev: 07f6ebadf0bc4a90bdba9106df7fb55be8d76ffd) Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com> Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Always use GCC toolchainKhem Raj2025-05-221-0/+2
| | | | | | | | | | GCC is not yet compilable with clang e.g. (From OE-Core rev: 28e84b252eb6c01956cad554e9c453412b45e51f) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix riscv multilib issues in plain toolchainsRichard Purdie2025-05-152-0/+11
| | | | | | | | | | | | | | | RISC-V multilib currently doesn't work at all. We could disable multilib for the riscv platform but that would then behave differently to all our others. Instead, copy the non-multilib config over the multilib config for now for riscv, meaning we can keep the platforms similar. This isn't quite enough as the triplet specific c++ headers are in the wrong place leading to compiler issues and testimage failures. Work around that too until someone adds full multilib support for the platform (if desired). (From OE-Core rev: 3081f62c18fcee642ab43efa717c8f71d51ae587) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Upgrade GCC to 15 releaseKhem Raj2025-05-0140-1439/+236
| | | | | | | | | | | | | | | | | | * Nios2 has been removed and aarch64/ilp32 is deprecated * Default C dialect is switched to C23 * {0} initializer in C or C++ for unions no longer guarantees clearing of the whole union * Compile speed improvements with LTO * Vectorizer can support loops with early exists but it is limited to loops with fixed vector lengths This is major release of gcc, the changes are noted [1] [1] https://gcc.gnu.org/gcc-15/changes.html (From OE-Core rev: 0ddda88b928a8b4e5ca3a4cc6112b8331cdff544) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Switch prefix mapping to use -ffile-prefix-mapKhem Raj2025-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | -ffile-prefix map is more comprehensive when it comes to reproducible builds and its superset of all prefix-mapping options in compilers This makes is cleaner and workable across gcc and clang, clang does not support -fcanon-prefix-map and it has to be explicitly omitted when using clang. There are lambdas generated in templates by clang which still get the absolute paths despite -fdebug-prefix-map, this helps with that as well. nasm is an outlier and we have fixed it by adding -fdebug-prefix-map option luckily we do not pass DEBUG_PREFIX_MAP to nasm, in all recipes which use nasm either pass -fdebug-prefix-map explicitly to nasm or they rewrite it to use nasm flags syntax. We have discussed this in past [1] [1] https://patchwork.yoctoproject.org/project/oe-core/patch/20230428032030.2047920-1-raj.khem@gmail.com/#10281 (From OE-Core rev: ff73fa7ef7666a6dbe34f15515bc3ab6e574c5b0) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Jacob Kroon <jacob.kroon@gmail.com> Cc: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Undef _TIME_BITS in sanitizer_procmaps_solaris.cppJiaying Song2025-04-102-0/+63
| | | | | | | | | | | | | | | | | | | | gcc-sanitizers fail to build when both -D_TIME_BITS=64 and -D_FILE_OFFSET_BITS=64 are defined. This is because sanitizer_procmaps_solaris.cpp explicitly undefines _FILE_OFFSET_BITS before including any headers, which causes _TIME_BITS=64 to violate the requirement in glibc: /usr/include/features-time64.h:26:5: error: "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" Fixes a build failure on 32-bit Linux platforms when using both -D_TIME_BITS=64 and -D_FILE_OFFSET_BITS=64. (From OE-Core rev: 902085def653ca5194b28a4065043c73e54c9204) Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Package libstdc++.modules.jsonKhem Raj2025-03-171-0/+1
| | | | | | | | | | | libstdc++.modules.json is new file in libstdc++ from GCC-15 it is the module mapping file used in C++ projects that utilize C++20 modules (From OE-Core rev: bbfe7ee5b64618649eb8aff753b444c97313e617) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-cross,gcc-cross-canadian: Drop symlinking gold linkerKhem Raj2025-03-172-2/+2
| | | | | | | | | Its not being built by binutils anymore (From OE-Core rev: b51c98d75437a4497fc727c1201b3f8d124deafa) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-sanitizers.inc: Workaround for aarch64Thomas Roos2025-01-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | When using the -fsanitize=address CXX_FLAG for a program compiled for aarch64 / arm64 This is happing: MemorySanitizer: CHECK failed: sanitizer_allocator_primary64.h:133 "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))" (0xe00000000000, 0xfffffffffffffff4) (tid=51745) With -DSANITIZER_CAN_USE_ALLOCATOR64=0 this is not happening and potenial bugs are detected. ARM32 does not require this patch. More info about the issue in this thread: https://github.com/llvm/llvm-project/issues/65144 (From OE-Core rev: 12442b9b6df06317174066854935b1d6a4f1865d) Signed-off-by: Thomas Roos <throos@amazon.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Ross Burton <ross.burton@arm.com>
* gcc: make include poisoning fatal again in gcc/g++Ross Burton2025-01-221-10/+27
| | | | | | | | | | | | | | | | | | | | | We have a patch to allow us to 'poison' system include directories, which are warnings by default but we make them fatal in cross builds. However, in the 13.1 upgrade[1] the patch to make the warnings fatal was dropped in the compiler invocation, so it only took effect for pure preprocessor calls. This was not noticed at the time as the test case was flawed, but this has now been fixed. Add back the fatal poisoning, and restructure the patch slightly so it is less invasive. [1] oe-core bea46612fd9106cc5b46eb1d81623b6492563c13 [RP: Tweak to fix gcc/gcc-cross-canadian failure] (From OE-Core rev: 56f21a02c009cb74072ee79467a5bcab3c4643a5) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* base: Switch virtual/cross-XXX to be under recipe specific providersRichard Purdie2025-01-211-1/+0
| | | | | | | | | | | | | | | Currently, providers are set on a global config basis. This change allows for a select set of providers to be configured using BB_RECIPE_VIRTUAL_PROVIDERS on a per recipe basis. This would allow for the selection of virtual/cross-cc as gcc or clang for example. The PROVIDERS are removed from the recipes so that if a version of the dependency accidentally slips through, the build will fail and the user can correct the issue. (From OE-Core rev: 6eeab1a5d7f23917b94c130e417d59afb757b546) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/recipes: Switch virtual/XXX-gcc to virtual/cross-cc (and c++/binutils)Richard Purdie2025-01-219-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea of the base class dependency is to say "yes, I need a C cross compiler" and this was never meant to be gcc specific. Looking at the codebase, whilst we code triplets into this, it does overcomplicate things as there are only ever limited, "target", "sdk" and the class extended versions like mutlilib. After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc. This lets us remove the "gcc" specific element as well as removing the over complicated triplet usage. At the same time, change the much less widely used "g++" variant to "c++" for similar reasons and remove the triplet from virtual/XXX-binutils too. Backwards compatibility mappings could be left but are just going to confuse things in future so we'll just require users to update. This simplification, whilst disruptive for any toolchain focused layers, will make improved toolchain selection in the future much easier. Since we no longer have overlapping variables, some code for that can just be removed. The class extension code does need to start remapping some variables but not the crosssdk target recipe names. This patch is in two pieces, this one handles the renaming with the functional changes separate in a second for easier review even if this breaks bisection. (From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: poison-system-directories patch updated for missing pathsSunil Dora2025-01-201-4/+18
| | | | | | | | | | | | | | Modified logic in gcc/incpath.cc to ensure that non-existing host system paths are not deleted during cross-compilation. If the build system attempts to search a host path, gcc will now issue a warning instead of silently ignoring it. Fixes [YOCTO #15672] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15672 (From OE-Core rev: 32e2f9a73a653a00e555e50f9197b605f2f70f89) Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemu/machine: rename QEMU_EXTRAOPTIONS for consistencyRoss Burton2025-01-111-1/+1
| | | | | | | | | | | | | | | | | The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH}, but this doesn't follow the pattern of all of the other tune-specific variables in the machine configuration which is VARIABLE:tune-[name]. Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} for consistency. Note that this will mean that BSPs need to update any assignments of this variable. (From OE-Core rev: 7f981d074442b901f7e64dbdb9db851ff31c3733) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/qemu: use tune to select QEMU_EXTRAOPTIONS, not package architectureRoss Burton2025-01-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Using the package architecture to select the right qemu options to pass to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are not typically any options set for the machine name. Solve this by using TUNE_PKGARCH instead: for the majority of recipes this is the same value, but for machine-specific recipes it remains the same instead of changing to the machine name. This means we can remove the qemuppc workarounds, as they're obsolete. Also update the gcc-testsuite recipe which uses the same pattern to use TUNE_PKGARCH, and generalise the else codepath to avoid needing to update the list of architectures. [ YOCTO #15647 ] (From OE-Core rev: 414b754a6cbb9cc354b1180efd5c3329568a2537) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: backport patch to fix data relocation to !ENDBR: stpcpyBin Lan2024-12-182-0/+448
| | | | | | | | | | | | | | | | | | There is the following warning when building linux-yocto with default configuration on x86-64 with gcc-14.2: AR built-in.a AR vmlinux.a LD vmlinux.o vmlinux.o: warning: objtool: .export_symbol+0x332a0: data relocation to !ENDBR: stpcpy+0x0 This change set removes the warning. PR target/116174 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116174] (From OE-Core rev: 30d4f18d1e11b3336c8668dccd96b9ff35c7bc76) Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix c++: tweak for Wrange-loop-constructSunil Dora2024-12-132-0/+115
| | | | | | | | | | | | | | | | | | | | | This commit updates the warning to use a check for "trivially constructible" instead of "trivially copyable." The original check was incorrect, as "trivially copyable" only applies to types that can be copied trivially, whereas "trivially constructible" is the correct check for types that can be trivially default-constructed. This change ensures the warning is more accurate and aligns with the proper type traits. LLVM accepted a similar fix: https://github.com/llvm/llvm-project/issues/47355 PR c++/116731 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116731] (From OE-Core rev: 7c9402953d1e4eed4bd4427171e96761812f7478) Signed-off-by: Marek Polacek <polacek@redhat.com> Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-sanitizers: Add riscv64 as compatible hostDeepthi Hemraj2024-12-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | RISC-V offers several virtual memory address schemes (Sv39, Sv48, and Sv57), but ASan currently supports only Sv39 on RISC-V64. For RISC-V64 Sv39, ASan uses custom allocator configurations tuned to manage large allocations efficiently. These tunings are incompatible with larger address spaces like Sv48/Sv57 due to differences in region sizes and alignment. For riscv64, Asan's tuning for Sv39 can be enabled in qemu by using the appropriate flag in the command line as shown below: runqemu nographic qemuparams="-cpu rv64,sv39=true" Additionally, the COMPATIBLE_HOST list in gcc-sanitizers has been updated to include riscv64. All necessary tests were successfully conducted on both hardware(Microchip PolarFire SoC) and the qemurisv64 environment, with ASan effectively detecting memory errors in both scenarios. (From OE-Core rev: 4b4450ff695ef73bf7a2437e142d2e0730d6a547) Signed-off-by: Deepthi Hemraj <Deepthi.Hemraj@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: remove unused JAVA variableRasmus Villemoes2024-12-031-1/+0
| | | | | | | | | | | | | | | | As commit 81551871b183 (gcc: Remove Java support variables) correctly stated Java support was removed in upstream gcc 7. but this line snuck back in with commit bbf32e24608c (gcc-9: Add recipes for gcc 9.1 release). (From OE-Core rev: 136619477f0ce7c9da0762bbbeb1227a1ad6c0c7) Signed-off-by: Rasmus Villemoes <ravi@prevas.dk> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: add a backport patch to fix an issue with tzdata 2024bMarkus Volk2024-11-232-0/+550
| | | | | | | | | | | | | There is an issue in the std::chrono::tzdb parser that causes problems since the tzdata-2024b release started using %z in the main format. As a real world problem I encounter an issue with the waybar clock module, which ignores the timezone setting and only shows system time. (From OE-Core rev: 39018429f05511053ab12e23e7f4487ea25ee529) Signed-off-by: Markus Volk <f_l_k@t-online.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgfortran: fix buildpath QA issueChen Qi2024-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The '-fdebug-prefix-map' options are used to map source files locations, otherwise, DW_AT_comp_dir will contain buildpath. The '-gno-record-gcc-switches' option is used to fix the buildpath introduced by '-fintrinsic-modules-path' option, which is automatically added by fortran. Here's some output from 'readelf --debug-dump libgfortran.so.5.0.0' when this option is not added: """ <0><1a37d3>: Abbrev Number: 4 (DW_TAG_compile_unit) <1a37d4> DW_AT_producer : (indirect string, offset: 0xd653): GNU Fortran2008 14.2.0 -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -mshstk -g -O2 -O2 -fstack-protector-strong -fimplicit-none -fno-repack-arrays -fno-underscoring -fcf-protection=full -fallow-leading-underscore -fbuilding-libgfortran -fPIC -fintrinsic-modules-path /ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/ core2-64-poky-linux/libgfortran/14.2.0/recipe-sysroot-native/usr/bin/x86_64-poky-linux /../../lib/x86_64-poky-linux/gcc/x86_64-poky-linux/14.2.0/finclude -fpre-include=../../../../recipe-sysroot/usr/include/finclude/math-vector-fortran.h """ See https://gcc.gnu.org/pipermail/fortran/2024-October/061204.html for more detailed information. (From OE-Core rev: 1eb084956bcba83782bc2b24cf8cc89459a57e34) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-source: Fix racing on building gcc-source-14.2.0 and lib32-gcc-source-14.2.0Hongxu Jia2024-10-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While enabling multilib, build gcc-source-14.2.0 and lib32-gcc-source-14.2.0 at the same time: $ MACHINE = "qemux86-64" $ require conf/multilib.conf $ MULTILIBS = "multilib:lib32" $ DEFAULTTUNE:virtclass-multilib-lib32 = "x86" $ bitbake gcc-source-14.2.0 lib32-gcc-source-14.2.0 ... $ cat tmp-glibc/work-shared/gcc-14.2.0-r0.vr2401/temp/log.task_order 20241012-064533.415426 do_recipe_qa (2688052): log.do_recipe_qa.2688052 20241012-064533.463783 do_recipe_qa (2688051): log.do_recipe_qa.2688051 20241012-064533.805164 do_fetch (2688257): log.do_fetch.2688257 20241012-064533.852955 do_fetch (2688256): log.do_fetch.2688256 20241012-064617.823714 do_unpack (2698542): log.do_unpack.2698542 20241012-064617.871730 do_unpack (2698541): log.do_unpack.2698541 ... There are two tasks for do_fetch, do_unpack and others, so there are race issues. Both of them have the same hardcode 'gcc' prefix in ${WORKDIR} and ${S}, explicitly disable lib32-gcc-source-14.2.0 for multilib Set gcc-source as BPN of gcc-source-14.2.0 (From OE-Core rev: 901c47877e0710af50639f688e0bfdb851b762b5) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix spurious '/' in GLIBC_DYNAMIC_LINKER on microblazeKhem Raj2024-09-051-3/+3
| | | | | | | | (From OE-Core rev: f0eac82b9a1e4549b7d918df768c369ed7ab5183) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Mark Hatle <mark.hatle@amd.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* oeqa/selftest/gcc: Fix host key verfication failureHarish Sadineni2024-08-131-1/+1
| | | | | | | | | | | | | | | | | | while runnig oe-selftest for gcc, testcases that need to be run on qemu are not running due to below failures. - Executing on ssh: mkdir -p /tmp/runtest.3549641 (timeout = 300) spawn [open ...] Host key verification failed. ERROR: Couldn't create remote directory /tmp/runtest.3549641 on ssh Host key verification failure is happening when ssh board config file name is defined as "ssh.exp" and there are multiple ssh.exp files generated during the build and a wrong ssh config was taken. To resolve this changed the board config file name to "linux-ssh.exp" which ensures correct ssh settings are used. (From OE-Core rev: d32ec0b4d242879ab8eaf96e1cb407e8f0bb9f3d) Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: enabling "network" task specific flagHarish Sadineni2024-08-131-0/+1
| | | | | | | | | | | | | | | Adding a "network" task specific flag which then triggers networking to be enabled for this task, it is otherwise disabled which will cause failures while running oe-selftest. Fixes the following issues while running oe-selftest for gcc: 1)ssh: connect to host X.X.X.X port 22: Network is unreachable. 2)Bad owner or permissions on /etc/ssh/ssh_config.d/50-redhat.conf. (From OE-Core rev: 35782416823fa863d26a338256f642f6bc480a96) Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Upgrade to GCC 14.2Khem Raj2024-08-0837-143/+66
| | | | | | | | | | | | This is first bugfix release in GCC14 release series 100+ bugfixes [1] [1] https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=14.2 (From OE-Core rev: 32b39de6a23f1e9ae5786d63f4c5849301eddbda) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: unify cleanup of include-fixed, apply to cross-canadianDenys Dmytriyenko2024-08-034-31/+8
| | | | | | | | | | | | | | | | | | | Since target and cross variants were already doing similar cleanup of include-fixed headers, as those aren't used, unify the code and also apply the same to cross-canadian variant. Some of those header files get processed with a tool that leaves absolute buildpaths inside the file's commented section, causing QA errors. Since those aren't used, let's remove them. This may be a temporary solution until the tool itself gets fixed to not embed absolute buildpaths in the header files: https://lists.openembedded.org/g/openembedded-core/topic/107268307 (From OE-Core rev: 9221e4ab8cca4c06dc3d5c1de2fd4ce46477578a) Signed-off-by: Denys Dmytriyenko <denys@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: remove paths to sysroot from configargs.h and checksum-options for ↵Oleksandr Hnatiuk2024-08-035-28/+29
| | | | | | | | | | | | | | | | | | gcc-cross-canadian Apply fixes from gcc-cross (84a78f46d594 and 0ead8cbdfb96) to gcc-cross-canadian. This will improve (but not fix) reproducibility of gcc-cross-canadian. Also move this code to functions to avoid code duplication. [RP: Tweak patch to make the function parameters clear and fix quoting issues ensuring the code exactly matches the original replacements with an additional parameter.] (From OE-Core rev: 350ff7d53f7506de2bc01f0efc569b8294b9afea) Signed-off-by: Oleksandr Hnatiuk <ohnatiuk@cisco.com> Signed-off-by: Denys Dmytriyenko <denys@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* tclibc-picolibc: Adds a new TCLIBC variant to build with picolibc as C libraryAlejandro Hernandez Samaniego2024-07-263-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enables usage of TCLIBC=picolibc extending OE functionality to build and use picolibc based toolchains to build baremetal applications. Picolibc is a set of standard C libraries, both libc and libm, designed for smaller embedded systems with limited ROM and RAM. Picolibc includes code from Newlib and AVR Libc, but adresses some of newlibs concerns, it retains newlibs directory structure, math, string and locale implementations, but removed the GPL bits used to build the library, swiches old C style code for C18 and replaces autotools with meson. This patch adds a picolibc recipe for the C library, a picolibc-helloworld recipe that contains an example application and a testcase that builds it. Picolibc can be built for ARM and RISCV architectures, its been tested both for 32 and 64 bits, the provided example recipe produces the following output: hello, world Runqemu does not automatically show any output since it hides QEMU stderr which is where the QEMU monitors output is directed to when using semihosting, but, manually running the same QEMU command does work properly. (From OE-Core rev: c7535ecaccb72ef21a61f9aec5c68e61fb4f6fb6) Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-14: Mark CVE-2023-4039 as fixed in GCC14+Khem Raj2024-07-181-0/+1
| | | | | | | | (From OE-Core rev: 47b838eea7e3684d6b00bb7196313f0bfa519aba) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgfortran.inc: fix nativesdk-libgfortran dependenciesMartin Jansa2024-06-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * use virtual/* variables as INHIBIT_DEFAULT_DEPS does to avoid dependency on gcc-cross- from nativesdk-libgfortran * the dependency was added in: https://git.openembedded.org/openembedded-core/commit/?id=00fba52c8a6f6383137cf89fc7aa34cc3e2ff45f causing: build/oe-core $ bitbake -g nativesdk-libgfortran NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'gcc-cross-x86_64' (but virtual:nativesdk:/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgfortran_14.1.bb DEPENDS on or otherwise requires it). Close matches: gcc-cross-aarch64 ... with: MACHINE=qemuarm64 FORTRAN:forcevariable = ",fortran" * after: https://git.openembedded.org/openembedded-core/commit/?id=44fc7aa1468ff042739cc5a91c84ef5c2a09e0a3 nativesdk-libgfortran is pulled as dependency of nativesdk-gcc so this affects more people who didn't explicitly use nativesdk-libgfortran before * the INHIBIT_DEFAULT_DEPS and gcc-runtime was there since gcc-4.8: https://git.openembedded.org/openembedded-core/commit/?id=a5e7ee5770b9e0cf719c573efffd874440f74289 (From OE-Core rev: 5ce2e9c66cd2c08e141913ec65386f940353a8c5) Signed-off-by: Martin Jansa <martin.jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gfortran: update runtime dependenciesKai Kang2024-06-181-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | It fails to run both `gcc` and `gfortran` with errors: | root@qemux86-64:~# x86_64-poky-linux-gcc a.c | x86_64-poky-linux-gcc: fatal error: cannot execute 'as': posix_spawnp: No such file or directory then add binutils which provides `as` to RDEPENDS of gcc. libgfortran-dev provides libgfortran.spec which required by gfortran: | root@qemux86-64:~# gfortran hello.f95 | gfortran: fatal error: cannot read spec file 'libgfortran.spec': No such file or directory And gcc provides liblto_plugin.so: | root@qemux86-64:~# gfortran hello.f95 | gfortran: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found (From OE-Core rev: 44fc7aa1468ff042739cc5a91c84ef5c2a09e0a3) Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: remove g77/f77Kai Kang2024-06-183-32/+2
| | | | | | | | | | | | | | | | | | | | | | | | g77/f77 has been removed from gcc 4.0.0 via commit: * b4117c30610 Makefile.def, [...]: Remove all mention of libf2c. When set FORTRAN = ",f77" it complains with error: | The following requested languages could not be built: f77 | Supported languages are: c,c,c++,fortran,go,lto,m2,objc,obj-c++ So remove g77/f77 from gcc recipes. [1]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b4117c30610 (From OE-Core rev: 6469c6a00066af24c87ec5dd7994ebbc610c3782) Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix typo in increment expression in unicode from libstdc++Khem Raj2024-06-182-0/+77
| | | | | | | | | | This issue is seen when libstdc++ headers are used by clang18 see - https://github.com/llvm/llvm-project/issues/92586 (From OE-Core rev: 1506b779014b09ffd618b2e5d95aa00ff91d6f45) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Allow using libc++Dan McGregor2024-06-124-6/+3
| | | | | | | | | | | | | With the addition of the C++ runtime setting added recently, allow gcc to use libc++ as its runtime. There's some minor fixes still required, such as allowing setting the unwinder library. But this allows for testing libc++ with gcc. (From OE-Core rev: f84ae97e2bc081c972e78ee4a958f21111dbbfb6) Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: libgomp fix for gcc 14 warnings with mandb selftestRichard Purdie2024-05-211-1/+1
| | | | | | | | | | | ERROR: gcc-runtime-14.1.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package: /usr/share/info /usr/share/info/libgomp.info-2 /usr/share/info/libgomp.info-1 (From OE-Core rev: 4f73ddd6c276dcd579d2113db1974d446dbf7751) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Upgrade to GCC 14.1 releaseKhem Raj2024-05-2139-3481/+212
| | | | | | | | | | | | | | | | | | This is major release upgrade. major changes are listed in [1] and it has a list of bugs [2] fixed as well This release may differ in significant ways from prior gcc releases where it may require port the code to gcc 14, there is a porting guide [3] available. [1] https://gcc.gnu.org/gcc-14/changes.html [2] https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=14.0 [3] https://gcc.gnu.org/gcc-14/porting_to.html (From OE-Core rev: fc48aa30e91ffe94f1012fe108fb1db5233a0bc0) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Oe-selftest failure analysis - fix for vect-simd test failuresHarish Sadineni2024-03-232-0/+27
| | | | | | | | | | | | | | | In gcc vect module, the vect-simd-clone-10.c & vect-simd-clone-12.c tests are failed with below error, due to a bug in testcase: xgcc: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with multiple files compilation terminated' Detailed bug info & upstream fix is here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899 Upstream Status: Backport [https://gcc.gnu.org/g:948dbc5ee45f9ffd5f41fd6782704081cc7c8c27] (From OE-Core rev: 50b6b938ec91dee346642b95cdcb35043be1697c) Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Oe-selftest failure analysis - fix for tcl errorsHarish Sadineni2024-03-181-2/+2
| | | | | | | | | | | | | | gcc testsuite unable to read the value of variable $do-what-limit and causing below tcl errors. ERROR: can't read "do": no such variable while executing "set do_what $do-what-limit" To fix this, quote the variable using braces, as in ${do-what-limit}. (From OE-Core rev: e59421468d96282057f5176438a76a325b987e47) Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Move gdb pretty printer file to auto-load locationKhem Raj2024-02-091-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | When debugging a C++ program on target using libcstdc++, gdb does not find the pretty printer python support, this is because the init file is installed into /usr/lib which is excluded from gdb's default list of directories to load config's from, where as defaults to load from datadir is still on, it therefore does not load this file warning: File "/usr/lib/libstdc++.so.6.0.33-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". This leaves the libstdc++ pretty-printers disabled even though added via IMAGE_INSTALL += "gcc-runtime-dbg" Comment on adding missing runtime dependency on datetime python module for the pretty printer to work/load successfully. Once the pretty-printer gdb file is moved out of libdir, it may become empty therefore delete it if its empty. (From OE-Core rev: d24e16d192f21aa68b5274496efaba1d913f37c2) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Update status of CVE-2023-4039Simone Weiß2024-01-261-0/+1
| | | | | | | | | | | | This is fixed via a patch added in gcc-13.2.inc already, but still reported e.g. for libgcc as it is not defining an own source but use the shared gcc-source. (From OE-Core rev: 301d45eacfd4ae6bddfb13207e2af9e8b4662bc8) Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: depend on zstdSean Nyekjaer2023-09-291-1/+1
| | | | | | | | | | | | | | | | | | | | Add zstd LTO support for target and nativesdk compiler. This also brings gcc into sync with gcc-cross. % x86_64-oe-linux-gcc -v [...] Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (GCC) % x86_64-oesdk-linux-gcc -v [...] Supported LTO compression algorithms: zlib gcc version 12.2.0 (GCC) (From OE-Core rev: 2f6e3d32ad73ef8e0e3d3b89702d85c36358c00c) Signed-off-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: backport a fix for ICE caused by CVE-2023-4039.patchMartin Jansa2023-09-203-71/+197
| | | | | | | | | | | | | | * see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 * add git headers to 0025-gcc-testsuite-mips.patch so that it does easily apply with other patches with git am (From OE-Core rev: 760068c5868380b0e833155020365735f55314c3) Signed-off-by: Martin Jansa <martin.jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix -fstack-protector issue on aarch64Ross Burton2023-09-132-0/+3094
| | | | | | | | | | | | | | | | This series of patches fixes deficiencies in GCC's -fstack-protector implementation for AArch64 when using dynamically allocated stack space. This is CVE-2023-4039. See: https://developer.arm.com/Arm%20Security%20Center/GCC%20Stack%20Protector%20Vulnerability%20AArch64 https://github.com/metaredteam/external-disclosures/security/advisories/GHSA-x7ch-h5rf-w2mf for more details. (From OE-Core rev: 750396ca55e9f165a77dc94f841a953b9a6520d5) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fresh 0003-64-bit-multilib-hack.patch to add loongarch64 supportZang Ruochen2023-09-091-1/+53
| | | | | | | | (From OE-Core rev: 1a209ef31165049c450018c7722013aa4d983fd8) Signed-off-by: Zang Ruochen <zangruochen@loongson.cn> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-07-04 05:56:29 +0000