I was able to make it work correctly enabling CMAKE_SKIP_RPATH. Here the working full recipe: LICENSE = "NCSA" LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=59d01ad98720f3c50d6a8a0ef3108c88 \ file://iwyu

#sdk

Hello, I wrote a kernel driver which exposes some header to userspace application. Application engineers use generated SDK, so I'd like to export that header file as part of SDK. I added my header to

#kernel #sdk

Good morning everybody, I would like to include IWYU in my SDK, but I couldn't find a recipe, so I'm trying to write my own. With the help of devtool, I came to something like this: LICENSE = "NCSA" L

#sdk

Thanks you...

#yocto #sdk #cmake

take a look at https://github.com/kraj/meta-clang/blob/master/recipes-core/meta/clang-environment.inc#L11-L19 perhaps that can be something you might find useful On Thu, Apr 22, 2021 at 11:51 AM Monse

#yocto #sdk #cmake

When setting up an SDK, (standard or extensible), build which will be using cmake, is there a proper way to pre-configure OEToolchainConfig.cmake for ones env/applications ? Currently I build the SDK,

#yocto #sdk #cmake

Any one seen this before… ? SDK appears to be working okay without the inclusion of native python3 components, not sure how the inclusion breaks devtool…

#yocto #sdk

Working with zeus 3.0.4, extended SDK… Could someone explain what I overlooked, or why this issue pops up with python-native support inclusion ? Thanks… When I add in native-python3 support # # Additi

#yocto #sdk

No the vivado module sets up key variables, the lib path, and the include paths for building Xilinx low level drivers built into bootapp/kernel... I need to be able to include these components in actu

#yocto #sdk

there is KERNEL_MODULE_AUTOLOAD which could be used to load modules on boot, don't know if that suffices to what you need but worth looking into. On Tue, Apr 6, 2021 at 12:47 PM Monsees, Steven C (US)

#yocto #sdk

Working with zeus, aarch64, with Xilinx vivado dependencies… Kerenl image and bootapp build and run correctly, need to be able to build EXT SDK,,, How do I incorporate the dependencies of the low leve

#yocto #sdk

EXT SDK, aarch64, zeus… How do I best modify the EXT SDK build env so as to reference the “vivado” env dependencies ? Is there a way to build in support so that the “module load” command would be usab

#yocto #sdk

Hi Can you try this patch ( if you are using master ) and see if that helps diff --git a/recipes-devtools/clang/clang_git.bb b/recipes-devtools/clang/clang_git.bb index b8986be..b0c81f1 100644 --- a/r

#sdk #dunfell #yocto #kernel #linux

Hello, I need Clang compiler apart from currently available default gcc compiler as I am trying to compile eBPF which will run on my custom yocto which is based on core-image-minimal. Therefore I adde

#sdk #dunfell #yocto #kernel #linux

For Arm EXT SDK support: Can I modify the EXT SDK build env paths from “sdk-extra.conf” so as to reference the “vivado” env? Is there a way to build in support so the “module load” command would be us

#yocto #sdk

Thanks for your patience… I was able to followed your advice and I am now able to build and install the Extended SDK for our Intel platform… Can you tell me when building for Arm/Xilinx based platform

#yocto #sdk

Perhaps get into install env and do signatures check for this task

#yocto #sdk

I've been looking at this but still find it odd that they are all " virtual:native"/ "poky/meta"/“do_populate_sysroot” related... It is a "minimum" plus "toolset" build... and it builds clean, yet fai

#yocto #sdk

Hello, Currently using Rocko to generate toolchains for ARM targets. Our BSP layer that is able to build a toolchain for our target architecture, ARM. I'd like to be able to add an x86 machine to this

#rocko #sdk #native

The output you see is from setting: SDK_EXT_TYPE = "minimal" SDK_INCLUDE_TOOLCHAIN = "1" When building minimal only, there are no errors/warnings (and no tools...)

#yocto #sdk