Probably, but again if you need a function from a library you include it on linker cmdline if it’s intrinsics then compiler driver doing the needed is best way Preferably without introducing

so while i'm still trying to wrap my head around all this, what *would* be the ideal resolution for this? the link above suggests the simple solution of introducing a gcc config

this would mean that you want to rely on side effects of -pthread which may work with gcc but may not work with clang or other compiler drivers. The issue you have is that some variables are needing

as i read it, this issue is also related to -pthread versus -lpthread: https://blog.jiejiss.com/A-RISC-V-gcc-pitfall-revealed-by-a-glibc-update/ rday

You shouldn't have to disable the sstate cache but glad you got it working. Which release series is that with? It does sound like there is a bug to fix somewhere in there. Cheers, Richard

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage Attendees: Steve Sakoman, Joshua Watt, Saul Wold, Alexandre Belloni, Paulo Neves, Richard Purdie, Aryaman Gupta, Randy Macleod,

it does indeed fix the curl build error, thanks. i haven't tested its operation yet, but getting a build was all i was after at the moment. rday

does backporting https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2 to curl help ?

Problem solved: the issue was actually that I was using a network sstate cache, and the cached output of gcc-cross did not contain gfortran. Disabling the sstate cache for gcc-cross causes gfortran to

another data point, matches exactly what i'm referring to: https://github.com/curl/curl/issues/9055 rday

on admittedly unsupported ubuntu 22.04 platform but it's clear this is a known issue as it's pretty much identical to what one reads here:

in your fortran app recipe you have to add DEPENDS = "libgfortran"

Hello, I'm trying to compile libgfortran for a Xilinx Zynq SoC, which uses the arm-xilinx-linux-gnueabi toolchain. I have added FORTRAN:forcevariable = ",fortran" to my local.conf, which causes

On 2022-06-30 11:21, Sakib Sajal wrote: This issue is understood, documented and resolved so I closed the defect with a short explanation. ../Randy -- # Randy

Maybe ‘deprecated’ isn’t quite the right word to use here. However, meta-gpl2 is unmaintained. It has no active maintainers, and is worked on only when absolutely needed: in the last year

Where and how the decision was made? Alex

meta-gplv2 is deprecated, so remove it from the autobuilder in master. Signed-off-by: Ross Burton <ross.burton@...> --- config.json | 11 ----------- 1 file changed, 11 deletions(-) diff --git

The meta-gplv2 layer is deprecated in master, so remove it from the check-layer job. Signed-off-by: Ross Burton <ross.burton@...> --- config.json | 5 +---- 1 file changed, 1 insertion(+), 4

Re-adding yocto@. It’s not always a trivial “this version”, there’s a fairly complex expression in the CVE (see the CPE entry) which needs to be evaluated. Or there may not be a fixed

Hello Gaurav, The CVE STATUS "Patched" means that there was an issue in the past, but it is either fixed or otherwise mitigated. Open issues are marked as "Unpatched". If you'd like to see only