|
Yocto Technical Team Minutes, Engineering Sync, for December 7, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for December 7, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, Stephen Jolley, Jasper Orschulko, Trevor Gamblin, Steve Sakoman, Philip Balister, Richard Purdie, Randy MacLeod, Peter Kjellerstedt, Jan-Simon Möller, Scott Murray, Alexandre Belloni, Tim Orling, Jon Mason, Bruce Ashfield, Ross Burton, Joshua Watt, Michael Opdenacker == project status == - 3.5-m1 (kirkstone) to be built this week - 3.4.1 (honister) out of QA and to be released - changes to check-layer script leads to improvements to layer README files - thanks to all for YPS last week - continue to remove local patches by sending upstream - rising intermittent issues with AB - SWAT faltering, large backlog of un-triaged issues == discussion == RP: Ross created graphs related to the changing number of patches and their state (from 2015 to now) http://www.burtonini.com/yoctometrics/ The patch status is clearly improving over time both in number and that they are generally moving upstream. 5 years ago we peaked at 1900 patches, today we’re at 1270-ish. It’s nice to note how much progress we can make when we put our resources towards it. Sometimes looking at a patch shows us that it is no longer required. Upstream is usually receptive, sometimes it’s just a matter of poking again. JPEW: i was working on meta-phosh and noticed that libsoup is all messed up now. there are 2 versions (v2 and v3) and you’re not supposed to mix-and-match. libsoup2 and 3 were both updated so that if they noticed the other one, they both hard fail (they call abort() on the process to kill it). previously things wouldn’t function correctly, now things won’t run at all. biggest offender is webkitgtk was upgraded to use libsoup3 but nothing else has been upgraded so anything links in webkitgtk crashes on startup. there are a surprising number of things in gnome that crash e.g. settings panel. Ross: probably easiest to add a packageconfig on webkit so distro maintainers get to pick JPEW: it looks like most things will probably switch to libsoup3 when they update to gtk4 (and won’t switch before then), but for now pretty much everything in meta-gnome is completely broken. currently libsoup3 is not used by anything other than webkitgtk Ross: probably should make libsoup2 the default for now to regress the breakage RP: sounds reasonable to me JPEW: at OEDVM we were talking about open-source projects getting Yocto compliance. i was working on meta-phosh but not sure what to do next. maybe next thing is to talk to the board? RP: not the board, talk to Nico. Nico is the gatekeeper for the compatibility process, and it goes to the TSC if required after. there are forms on the website, but the website is iffy, so if you fill in the forms and nothing happens, then reach out to Nico directly. it’s probably best to just reach out to Nico directly. RP: something that may be landing in the next few days, Ross is recommending that we remove libtool prefix. libtool is prefixed with an architecture prefix. this is something that OE and buildroot did early on and we’ve been carrying this for decades. there was a time when it looked like autoconf was going to mandate that build tools had the cross-compiler triplet prepended, but autotools looks dead now-a-days. ironically libtool rejected the patches Ross: everything it was trying to solve is now solved with recipe-specific sysroots, and host tools, etc. so everything should just work. any recipe that has to hand-code libtool work-arounds can all be removed now. i expect the fallout to be substantial, but the fixes will be to just remove stuff from recipes. does buildroot still do this? RP: not sure Ross: i don’t see any patches for libtool at all (in buildroot) RP: the cross-compile support in upstream libtool is broken; well, not broken but inefficient. but, as Ross says, it is obsolete now. Ross: lots of diffstat lines removed, but it will make the AB explode AlexB: buildroot has patches for libtool, even multiple versions (see support/libtool, not package/libtool) Ross: ah, i was looking in the wrong place RP: is supporting multiple versions of libtool not a path to madness? supporting one version is bad enough… Ross: it looks like it’s doing the same as our patches (i.e. fixing the relink thing) RP: yes, buildroot is patching for the the relink thing (which is something we do as well) but the prefix patch isn’t in buildroot Ross: i’ll clean this up and post it as an RFC at least RP: sounds good Ross: going back to the chart thing, there was talk a while ago about the LF having a centralized git monitoring/metrics thing? RP: LFX Ross: ah yes! is it still going? can we add our stuff into it? it would be nice to inject out patch data stuff there RP: they are still doing it, and there are developers actively working on it, but the people working on it have more pressing things to work on. so the answer is yes, but not now. there are lots of stuff i’d like to do this with, e.g. CVE metrics is another. it would be nice to find someone who would be interested in generating dashboard data for the project from what we’re producing. we have the ability to inject this stuff, we just need to generate it TimO: we need a data scientist Jon: i sent out an email about inclusive language, please read and respond RP: where? Jon: main yocto, oe-devel, oe-core. trying to get the ball rolling to see if it can land this release MO: i’m interested, it ties in with documentation RP: me too RP: Quentin sent a patch to rename… core-image-master (?) to golden instead. this is part of the QA test framework and was from a time when we had ideas about test controllers etc. i checked with the QA team and they aren’t using it. i did a double-take on that name, it’s not something i’ve used recently and there haven’t been any patches for it in ages. i had completely forgotten about its existence, despite being listed as the maintainer! is anyone using this code? JPEW: core-image-test-master ScottM: i had never heard of it before Ross: i almost ripped it out a few weeks back when i was doing a cleanup of the QA code. there is someone who is either using that code, or a derivative of it. i’ll copy them in on that thread so they can have an opinion. but if it’s not being used then it can probably be deleted. RP: rather than rename, i’m very tempted to just delete it. it’s not used and likely broken. even if someone is using it, there are probably better things they should be doing RP: there’s another breaking change to one of the tunes that we should probably fix before M1… Jon: A72? RP: yes, thanks. the crypto extension is enabled by default in the tune, but there’s now an rpi4 that has an SoC that doesn’t enable it. there are 2 ways to fix this: 1) leave the current tune as-is and create a -nocrypto variant 2) change the current tune to remove the crypto, then add a -crypto variant. not sure what path to take; i’m leaning towards the latter since that fits in better with the rest of the framework even if it is more disruptive. tune stuff is already complicated, i’d rather we keep the framework consistent. i also would prefer a better commit comment Jon: should i respin their patch with the updated wording? or comment on it to have them updated it? RP: either way; preferred to have it before -m1 Jon: just to be clear, this won’t break anything, it’ll just make it slightly less performant RP: right, and i think that’s reasonable ScottM: only meta-raspberrypi is affected by this? Jon: meta-raspberrypi is broken by this ScottM: oh right, after this change everyone else will have this off Jon: right. meta-raspberrypi, meta-rockchip, and possibly a freescale layer will be affected JPEW: so just manually re-enable it? Jon+RP: exactly Jon: yes, change to cortex-a72 + crypto RP: anyone using SH4? or anyone know of someone using it? Randy: nobody we know of (WindRiver) ScottM: nobody that I know of (AGL) MO: it’s an SoC for settop boxes (?) ScottM: maybe Khem would know RP: Khem is the one who patched it in the past, but not sure if he’s doing it because he’s using it (or knows someone using it) or if he’s just doing it because he’s aware of the patches RP: I came across this as part of the patch clean up exercise; there are some SH4 patches we’re carrying for glibc. we need to decide if we’re going to support this going forward. i’m under the impression that if someone wanted to get SH4 working, they would need more than these glibc patches. it would probably be better as an external architecture port/layer rather than odd, random hacks in oe-core ScottM: if Khem signs off on it then it sounds reasonable to me RP: i’ll talk to Khem Peter: i’ve noticed a problem with debug packages with honister. in june there was a change to remove the attempt-only for complimentary packages, so they are no longer called with skip-broken complimentary packages. this hid issues in our packaging. in our case we use gstreamer plugins (bad maybe) for srtp. the thing is we also have our own plugin for srtp. so we build the gstreamer plugin for srtp both as part of the gstreamer-bad package and from our own package. this works fine for the product images (since each plugin is put in its own package) but the debug symbols are all put in one package. meaning there is a clash for installing the debug symbols for both gstreamer and our package. is there any support for splitting the debug packages (similiar to how the main package is split), or are debug packages expected to all be all in one package? JPEW: are you asking if you can split? currently there is one debug package per recipe Peter: exactly. but because we are mixing plugins between 2 packages, the debug symbols clash. i would like the debug packages split just like the plugin packages are split. and i don’t know how the complimentary stuff works; and how it knows, for each plugin, that it should pick up the common debug package rather than the debug package that has the same name as the plugin package RP: it’s a good question. i’ve wondered about this in the past. yours isn’t the only scenario where you can hit this problem. the downside is the extra impact on the build. generating all these extra packages, and putting these extra packages into the package feed, etc.. will have an impact on the overall build and i’m not sure it will make anything more usable. it would fix some things, but cause other things. i also wouldn’t underestimate the amount of work involved to get this to work. RP: the easier fix is to make the files non-overlapping (by renaming) Peter: the problem is that our srtp is a drop-in replacement, so the plugins (files) are called exactly the same (they have to be) so you get the same file in both packages RP: you could make it a symlink (the debug symbols will be based on the original file, not the symlink), if you rename the file but made a symlink that might get around the issue Peter: interesting idea… RP: we’ve moving the goal-posts, but i think the symlink path would be easier TrevorW: honister-specific? Peter: yes, there was a change (june 28) in the package manager. previously, the complimentary packages were built attempt-only=true so dnf was called with the skip-broken option which ended up hiding the issue. it would ignore installing one of the packages at random. so previously there was a chance that symbols wouldn’t be there, and nobody would notice unless they were specifically needing those symbols. the honister change is an improvement since it makes it obvious when an issue comes up. ScottM: it would be nice to have the debug packages setup the same way other distros do, but if it blows up the build times, then that would probably not be worth it. it would be nice if someone had the cycles to prototype it so we’d have the data RP: it’s probably optimizable to some extent. we have some crazy build times for things like packaging ltp. for ltp it probably doesn’t matter, but for perl-modules it probably does. if you add more packages the build time scales badly. one of the implications would be separate debug symbols for each kernel module, which would at least double the number of packages in a kernel build Peter: for us we’d just do it for gstreamer, since that’s the only one causing us issues. in an ideal world everything would be handled the same RP: you can do that and the system will let you do that, but that’s not a change i’d take into core. currently the policy is to have 1 debug package per recipe, and that’s not something we’re about to change. separate debug packages will work, but will affect build times Peter: i could just remove the debug symbols for one of the packages, and hope nobody ever needs to debug it RP: separate debug packages will work, but we’re not going to change the policy Peter: i also have a similar problem with hardknott (which still has the keep-broken option enabled) so i can’t figure that out. similar, but not the same TrevorW: there was discussion around having more of a presentation + discussion style meeting each month at the OE happy hour Jon: possible, we have done it in the past, we’re open to it, but it’s hard to get people to do it (and having them do the prep). but having a YPS gives people something to shoot for. lots of work to do a presentation, OEHH is more informal. it would need someone or something to drive it and make it more formal. Paul Barker has done a couple show-and-tells informally at some OEHHs TimO: i like the spontaneous show-and-tell Jon: most people are trained to think in terms of conferences and doing presentations there. trying to do it informally might make it less likely to happen. we can take it to the board RP: i’ve been chatting with Khem and he says the SH4 patches are there because i wanted them in, so i guess i’ll remove them
|
||
|
|
||
|
Re: Using FreeRadius project on Yocto
On Tue, Dec 14, 2021 at 11:34 AM Rakesh Kumar <rakeshkumar0815@...> wrote:
just adding layer is not enough, you have to add it to your image as well via IMAGE_INSTALL or some other way as indirect dependency
|
||
|
|
||
|
Re: Yocto BUILD ENV
Monsees, Steven C (US)
So, I ran SDK build using “bitbake sbcb-defaults-full –k –c populate_sdk_ext”
Everthing builds under the SDK except 1 component … the intel-graphics-compiler-native/1.0.11-r0, which fails a few times for the header file reference shown below.
It also appears as though :
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++
Is pointer to the correct devtoolset-8 version
I feel as though I am missing something with regards to the EXT SDK env, but not sure what,,,
I have tried adding the “source /opt/rh/devtoolset-8/enable” to /etc/bashrc, /etc/profile, and have tried running “scl enable devtoolset-8 bash” prior to build… (all of which work correctly building the standard SDK, and my kernel image which are building in the IGC…
Sample error output:
| [63/565] /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++ -DCL_KHR_FP64_EXT -DGHAL3D=USC -DICBE_LINUX -DIGC_CMAKE -DIGC_EXPORTS=1 -DIGC_SPIRV_ENABLED -DINSIDE_PLUGIN -DISTDLIB_UMD -DLINUX -DNDEBUG -DNOMINMAX -DSTD_CALL -DUSC_EXPORTS=1 -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -D_AMD64_ -D_COMPILER_DLL_ -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_IGC_ -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/WrapperLLVM/include -IIGC/autogen -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../Common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/API -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../visa/include -IIGC/Release -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/ocl_igc_shared/executable_format -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/cif/cif/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler -isystem/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include -pipe -fno-exceptions -fdata-sections -ffunction-sections -O2 -fmessage-length=0 -march=corei7 -mstackrealign -fms-extensions -Werror -Wno-unused-parameter -Wno-missing-field-initializers -Wwrite-strings -Wno-long-long -Wswitch -Wno-sign-compare -Wno-unused-result -Wno-enum-compare -Wno-type-limits -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-extra -Wno-write-strings -finline -fno-strict-aliasing -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -Wno-unknown-pragmas -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector -finline-functions -funswitch-loops -Wno-maybe-uninitialized -lrt -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -DNDEBUG -g -std=gnu++14 -MD -MT IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -c /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp | FAILED: IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o | /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++ -DCL_KHR_FP64_EXT -DGHAL3D=USC -DICBE_LINUX -DIGC_CMAKE -DIGC_EXPORTS=1 -DIGC_SPIRV_ENABLED -DINSIDE_PLUGIN -DISTDLIB_UMD -DLINUX -DNDEBUG -DNOMINMAX -DSTD_CALL -DUSC_EXPORTS=1 -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -D_AMD64_ -D_COMPILER_DLL_ -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_IGC_ -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/WrapperLLVM/include -IIGC/autogen -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../Common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/API -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../visa/include -IIGC/Release -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/ocl_igc_shared/executable_format -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/cif/cif/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler -isystem/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include -pipe -fno-exceptions -fdata-sections -ffunction-sections -O2 -fmessage-length=0 -march=corei7 -mstackrealign -fms-extensions -Werror -Wno-unused-parameter -Wno-missing-field-initializers -Wwrite-strings -Wno-long-long -Wswitch -Wno-sign-compare -Wno-unused-result -Wno-enum-compare -Wno-type-limits -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-extra -Wno-write-strings -finline -fno-strict-aliasing -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -Wno-unknown-pragmas -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector -finline-functions -funswitch-loops -Wno-maybe-uninitialized -lrt -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -DNDEBUG -g -std=gnu++14 -MD -MT IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -c /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp | In file included from /usr/include/sys/stat.h:106, | from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47, | from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42, | from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp:44: | /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ token | __syscall_slong_t __unused[3]; | ^ | /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ token | __syscall_slong_t __unused[3]; | ^
From: yocto@... <yocto@...>
On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, December 14, 2021 2:23 PM To: yocto@... Subject: [yocto] Yocto BUILD ENV
I am using a pre-installed tools on my linux development box for centos7, that being devtoolset-8…
Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, kernel, and the standard SDK without issues…, but there seems to be a problem when I go to build the extended SDK.
It appears to end up referencing the wrong/default tool set.
Is the something I need to set in my sdk-extra.conf (or one of the vcarious other configuration files) to make the extended SDK build aware of the environment dependency ?
/opt/rh/devtoolset-8/enable script does the following:
# General environment variables export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}} export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH} export INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}} export PCP_DIR=/opt/rh/devtoolset-8/root # Some perl Ext::MakeMaker versions install things under /usr/lib/perl5 # even though the system otherwise would go to /usr/lib64/perl5. export PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}} # bz847911 workaround: # we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time # or else /etc/ld.so.conf.d files? rpmlibdir=$(rpm --eval "%{_libdir}") # bz1017604: On 64-bit hosts, we should include also the 32-bit library path. if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}" fi export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} # duplicate python site.py logic for sitepackages pythonvers=2.7 export PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}} export PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}
|
||
|
|
||
|
Using FreeRadius project on Yocto
Rakesh Kumar <rakeshkumar0815@...>
Hi Team, I am trying to build radius server with the use of Yocto project and looks like freeradius recipe is already included in meta-openembedded/meta-networking/recipes-connectivity/freeradius I have included meta-openembedded layer in my conf/bblayers.conf file and built core-image-base image. But I couldn't see anything related to radius server in my <workspace>/tmp directory "tmp/work/ccimx6ul/core-image-base/1.0-r0/rootfs/etc/init.d" Could you please let me know do I need to add anything specific to build radius server apart from using meta-openembedded recipe? I apologize if this is the wrong mailing list. Thanks much! Best Regards Rakesh kumar
|
||
|
|
||
|
Yocto BUILD ENV
Monsees, Steven C (US)
I am using a pre-installed tools on my linux development box for centos7, that being devtoolset-8…
Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, kernel, and the standard SDK without issues…, but there seems to be a problem when I go to build the extended SDK.
It appears to end up referencing the wrong/default tool set.
Is the something I need to set in my sdk-extra.conf (or one of the vcarious other configuration files) to make the extended SDK build aware of the environment dependency ?
/opt/rh/devtoolset-8/enable script does the following:
# General environment variables export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}} export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH} export INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}} export PCP_DIR=/opt/rh/devtoolset-8/root # Some perl Ext::MakeMaker versions install things under /usr/lib/perl5 # even though the system otherwise would go to /usr/lib64/perl5. export PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}} # bz847911 workaround: # we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time # or else /etc/ld.so.conf.d files? rpmlibdir=$(rpm --eval "%{_libdir}") # bz1017604: On 64-bit hosts, we should include also the 32-bit library path. if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}" fi export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} # duplicate python site.py logic for sitepackages pythonvers=2.7 export PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}} export PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}
|
||
|
|
||
|
Re: [meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf
On Tue, Dec 14, 2021 at 3:39 AM Quentin Schulz
<quentin.schulz@...> wrote: perhaps applying the sed expression via do_configure:prepend() is simple ? and maybe make it rk3399 specific with do_configure:prepend:rk3399 --
|
||
|
|
||
|
Yocto Project Status WW50`21
Stephen Jolley
Current Dev Position: YP 3.5 M1 Next Deadline: 6th Dec. 2021 YP 3.5 M1 build
Next Team Meetings:
Key Status/Updates:
Ways to contribute:
YP 3.5 Milestone Dates:
Upcoming dot releases:
Tracking Metrics:
The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC
The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||
|
|
||
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.5_M1.rc2)
Teoh, Jay Shen
Hi everyone,
toggle quoted messageShow quoted text
Intel and WR YP QA is planning for QA execution for YP build yocto-3.5_M1.rc2. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowTurbot 32-bit 2. Coffee Lake 3. NUC 7 4. NUC 6 5. Edgerouter 6. Beaglebone ETA for completion this Friday, 17th of December. Thanks, Jay
-----Original Message-----
|
||
|
|
||
|
Re: echo and read shell script functions in post install script doesn't display messages
Alexander Kanavin
The postinst scriptlets are script fragments and not standalone scripts. Putting an interpreter to their first line will not work. Also, they are not running on an interactive console, but by a helper executor, so they have to be entirely automated. What is the problem that you would like to solve? Alex
On Tue, 14 Dec 2021 at 13:01, <sanjaycvr35412@...> wrote:
|
||
|
|
||
|
echo and read shell script functions in post install script doesn't display messages
sanjaycvr35412@...
Hi All,
I am trying to execute a script in “pkg_postinst_ontarget_${PN}” to configure the static IP address of the embedded board. The script executes at first boot, but it doesn’t display echo or read messages. These messages are required to improve user experience with the setup process.
Script is as below: pkg_postinst_ontarget_${PN} () { #!/bin/sh -e # This will run on first boot echo "Starting setup script..."
read -p "Enter the IP address: " ipAddress read -p "Enter the netmask: " netmask read -p "Enter network gateway: " gateway
cat >> /etc/network/interfaces << EOF
iface eth0 inet static address $ipAddress netmask $netmask gateway $gateway EOF }
Please help me to fix the problem in displaying echo and read messages to improve user experience with the setup process.
Thanks, Sanjay Kumar
|
||
|
|
||
|
Re: [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf
Quentin Schulz
Sorry, this was meant for meta-rockchip, sending a new mail with the
toggle quoted messageShow quoted text
proper topic. Cheers, Quentin
On Tue, Dec 14, 2021 at 10:50:18AM +0100, Quentin Schulz wrote:
Not all Rockchip boards have their console running at 1500000 baud in
|
||
|
|
||
|
[meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf
Quentin Schulz
Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based SoM+Carrierboard. In order to prepare for the addition of puma-haikou to meta-rockchip, let's replace the baudrate in TF-A by the one defined in the machine conf file in the RK_CONSOLE_BAUD variable. Cc: Quentin Schulz <foss+yocto@...> Signed-off-by: Quentin Schulz <quentin.schulz@...> --- v2: use a less restrictive regular expression .../files/serial-console-baudrate.patch | 36 ------------------- .../trusted-firmware-a_%.bbappend | 6 +++- 2 files changed, 5 insertions(+), 37 deletions(-) delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch deleted file mode 100644 index 2d6e9bf..0000000 --- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch +++ /dev/null @@ -1,36 +0,0 @@ -From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001 -From: Yann Dirson <yann@...> -Date: Tue, 6 Apr 2021 17:28:45 +0200 -Subject: [PATCH] Set serial console baudrate back to 1500000. -Upstream-Status: Inappropriate[other] - -TF-A runs between two u-boot stages which both uses 1500000 baud, it -just makes no sense to use the same UART at a different rate. - -This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62. -Main reason for that change stated in https://developer.trustedfirmware.org/T762 -is ChromeOS compatibility. - -Looks like this patch may become unnecessary in the future, when -u-boot and TF-A get to communicate this value. - ---- - plat/rockchip/rk3399/rk3399_def.h | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h -index ba83242eb..8d6ecfbe6 100644 ---- a/plat/rockchip/rk3399/rk3399_def.h -+++ b/plat/rockchip/rk3399/rk3399_def.h -@@ -17,7 +17,7 @@ - /************************************************************************** - * UART related constants - **************************************************************************/ --#define RK3399_BAUDRATE 115200 -+#define RK3399_BAUDRATE 1500000 - #define RK3399_UART_CLOCK 24000000 - - /****************************************************************************** --- -2.30.2 - diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend index 513cea1..07fae1e 100644 --- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend +++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend @@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328" FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "\ - file://serial-console-baudrate.patch \ file://0001-dram-Fix-build-with-gcc-11.patch \ file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \ file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \ @@ -19,3 +18,8 @@ SRC_URI += "\ # this needs fixing until then use gcc TOOLCHAIN:rk3399 = "gcc" +fixup_rk3399_baudrate() { + sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h +} + +do_patch[postfuncs] += "fixup_rk3399_baudrate" -- 2.33.1
|
||
|
|
||
|
Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11
Quentin Schulz
Hi all,
On Mon, Dec 13, 2021 at 05:30:05PM -0500, Trevor Woerner wrote: Hi Quentin/Khem,No frustration on my side, just a debate/discussion on what we should do. Would this have been solved by (me) creating a honister branch? I usuallyNo, the problem is the same because it is broken only in Honister 3.4. So if we take this patch in, we basically have some code only for "patching" honister 3.4 but anything different than that, the patch is not necessary. So with a honister branch the "problem" stays the same. The question is more what's the policy with that kind of patch. Would you be ok taking that kind of patch which applies only to one dot release of Yocto and nothing else? Or do we just ignore it until the next dot release so it's fixed? Also do we expect to support honister 3.4 or once 3.4.1 is out (it is), we decide 3.4 is not supported at all? I'd like at least to mention somewhere that meta-rockchip is supposed to be used with something different than honister 3.4. Anyway, it's ok not to answer now and hope a similar issue does not happen later, or this discussion will be brought up again :) Cheers, Quentin
|
||
|
|
||
|
Re: [meta-rockchip][PATCH] trusted-firmware-a: replace baudrate with the one specified in machine conf
Quentin Schulz
Hi Trevor,
On Mon, Dec 13, 2021 at 05:37:32PM -0500, Trevor Woerner wrote: On Fri 2021-12-10 @ 11:15:56 AM, Trevor Woerner via lists.yoctoproject.org wrote:Yes, sorry just sent it :)On Fri 2021-12-10 @ 03:50:19 PM, Quentin Schulz wrote:Am I correct in thinking a v2 is coming (or did it get swallowed up by my mailHi Trevor,Sounds good. Cheers, Quentin
|
||
|
|
||
|
[PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf
Quentin Schulz
Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based SoM+Carrierboard. In order to prepare for the addition of puma-haikou to meta-rockchip, let's replace the baudrate in TF-A by the one defined in the machine conf file in the RK_CONSOLE_BAUD variable. Cc: Quentin Schulz <foss+yocto@...> Signed-off-by: Quentin Schulz <quentin.schulz@...> --- v2: use a less restrictive regular expression .../files/serial-console-baudrate.patch | 36 ------------------- .../trusted-firmware-a_%.bbappend | 6 +++- 2 files changed, 5 insertions(+), 37 deletions(-) delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch deleted file mode 100644 index 2d6e9bf..0000000 --- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch +++ /dev/null @@ -1,36 +0,0 @@ -From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001 -From: Yann Dirson <yann@...> -Date: Tue, 6 Apr 2021 17:28:45 +0200 -Subject: [PATCH] Set serial console baudrate back to 1500000. -Upstream-Status: Inappropriate[other] - -TF-A runs between two u-boot stages which both uses 1500000 baud, it -just makes no sense to use the same UART at a different rate. - -This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62. -Main reason for that change stated in https://developer.trustedfirmware.org/T762 -is ChromeOS compatibility. - -Looks like this patch may become unnecessary in the future, when -u-boot and TF-A get to communicate this value. - ---- - plat/rockchip/rk3399/rk3399_def.h | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h -index ba83242eb..8d6ecfbe6 100644 ---- a/plat/rockchip/rk3399/rk3399_def.h -+++ b/plat/rockchip/rk3399/rk3399_def.h -@@ -17,7 +17,7 @@ - /************************************************************************** - * UART related constants - **************************************************************************/ --#define RK3399_BAUDRATE 115200 -+#define RK3399_BAUDRATE 1500000 - #define RK3399_UART_CLOCK 24000000 - - /****************************************************************************** --- -2.30.2 - diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend index 513cea1..07fae1e 100644 --- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend +++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend @@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328" FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "\ - file://serial-console-baudrate.patch \ file://0001-dram-Fix-build-with-gcc-11.patch \ file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \ file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \ @@ -19,3 +18,8 @@ SRC_URI += "\ # this needs fixing until then use gcc TOOLCHAIN:rk3399 = "gcc" +fixup_rk3399_baudrate() { + sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h +} + +do_patch[postfuncs] += "fixup_rk3399_baudrate" -- 2.33.1
|
||
|
|
||
|
Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11
Quentin Schulz
Hi Trevor,
toggle quoted messageShow quoted text
Gentle ping :) Honister 3.4.1 being out it's less of an issue but the question remains at least for settling on a policy :) Cheers, Quentin
On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:meta-rockchip does not have honister branch for now. So it expects
|
||
|
|
||
|
Re: [meta-rockchip][PATCH] trusted-firmware-a: replace baudrate with the one specified in machine conf
Quentin Schulz
Hi Trevor,
On Fri, Dec 10, 2021 at 09:43:39AM -0500, Trevor Woerner wrote: On Thu 2021-11-11 @ 06:00:02 PM, Quentin Schulz wrote:WouldNot all Rockchip boards have their console running at 1500000 baud inThis looks fragile to me, any change in the number of spaces/tabs and this sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE plep/" ${S}/plat/rockchip/rk3399/rk3399_def.h work for you? This makes sure that only RK3399_BAUDRATE definition will be changed, no comment, no RK3399_BAUDRATE_OTHER_VAR or RK3399_BAUDRATE being used in code/other constant in this file. Cheers, Quentin
|
||
|
|
||
|
#dunfell #qt5 #raspberrypi #sdk #linux
#dunfell
#qt5
#raspberrypi
#sdk
#linux
arthur.forey@...
Hello everybody,
I come today to try to solve my problem. I am building a bsp and sdk for a raspberry pi (MACHINE = raspberrypi4-64) in the form of a compute module. I'm trying to compile this app: https://github.com/YvesBas/Tadarida-D/tree/master/sources for the raspberry pi). I know that in the Libs directory, the libraries are compiled for an x86_64 architecture. This is why I try to integrate them into the sources without this directory. I am also modifying the .pro to match with the correct libs. The integration of these two libs are present in the image of the raspberry pi, but in the sdk I only have the libsndfile1, so the libfftw3.h / .so is missing. Here are elements for the creation of the bsp and the sdk: Build Configuration: BB_VERSION = "1.46.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "aarch64-poky-linux" MACHINE = "raspberrypi4-64" DISTRO = "poky" DISTRO_VERSION = "3.1.12" TUNE_FEATURES = "aarch64 cortexa72 crc crypto" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "dunfell:cf5a00721f721d5077c73d1f4e812e5c79833fba" meta-oe meta-python meta-networking meta-multimedia = "dunfell:69f94af4d91215e7d4e225bab54bf3bcfee42f1c" meta-qt5 = "dunfell:b4d24d70aca75791902df5cd59a4f4a54aa4a125" meta-raspberrypi = "dunfell:934064a01903b2ba9a82be93b3f0efdb4543a0e8" In conf/local.conf : IMAGE_INSTALL_append = " libfftw libfftwl libfftwf fftw-dev libsndfile1" When I do bitbake meta-toolchain-qt5, I don't have libfftw3.h / .so . What can i do ? Thanks a lot. Arthur
|
||
|
|
||
|
libsdl2 virtual/nativesdk-libgles2 issue
sateesh m
Hi Team,
I am facing a problem libsdl2 while building the core-image-base. Can anybody know this please suggest me. NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/nativesdk-libgles2' (but virtual:nativesdk:/home/sateesh/sample-kde/openembedded-core/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb DEPENDS on or otherwise requires it). Close matches:
virtual/nativesdk-libgl
virtual/nativesdk-libsdl
virtual/nativesdk-libsdl2
NOTE: Runtime target 'nativesdk-qemu' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
NOTE: Runtime target 'nativesdk-packagegroup-sdk-host' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-packagegroup-sdk-host', 'nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-base', 'nativesdk-packagegroup-sdk-host', 'nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
Regards, Sateesh
|
||
|
|
||
|
Re: Running unittests built by SDK
On Mon, Dec 13, 2021 at 6:21 PM Rusty Howell <rustyhowell@...> wrote:
I think using qemux86-64 might be your best bet, its fairly automated with runqemu script all you would need to do is package up the gtests as ptest package with a runner Thanks
|
||
|
|