this is fine, if you are interested submit it as a patch to include in metadata in meta-python

#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

Thanks you...

#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

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

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, 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

Thanks again, these utilities make it much easier to understand and correct the issues...

#yocto #sdk

Hi, We have a functioning image built for our device/platform based on Ti Processor SDK 04.03.00.05; at this point I'm trying to build an SDK for the image that I can distribute to other members of ou

#toolchain #sdk #qt5

That means it’s having issues with checksums is there any AUTOREV being used ? I would suggest to build without your changes and see if you can get an eSDK

#yocto #zeus #sdk

Hello Alexander, I have two ideas that might get you closer. 1) First, I noticed that using TOOLCHAIN_HOST_TASK += "xxx" is broken on Yocto dunfell for me (non-extensible SDK). The issue is that even

#sdk

Hi Team, I've built OS for rpi3 using dunfell yocto. I've also generated SDK for the same, for that I've added these info in my local.conf file- TOOLCHAIN_TARGET_TASK_append = " python3-dev kernel-dev

#dunfell #raspberrypi #sdk

Hi All, I'm in serious task here and I need to cross compile a Cmake project. I need to send an SDK to a client with steps to cross compile the project. This project is compiling successfully via a Yo

#sdk #yocto #toolchain

Hello Henrik, As far as I known: - The -dev packages do not end up in target rootfs, unless you specify them in your target image. - The -dev packages end up in the standard SDK target sysroot if you

#yocto #sdk

On Thu, Oct 1, 2020 at 7:42 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote: drm_intel is in upstream kernel isn't it ? So just check

#yocto #sdk

Yes, I did this... I am currently down to 1 issue: /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp: In function ‘bool gbe::llvmToGen(gbe::ir::Unit&, const void*, int, bo

#sdk #yocto

Khem: Was there a bug between Clang/cmake in setting up "CMAKE_SHARED_LINKER_FLAGS" ? If you notice,when I set the default compiler to clang, it sets the –sysroot to my build area… this should be my t

#sdk #yocto

The following patch was the problem with the compiler-rt component of meta-clang: under : meta-clang/recipes-devtools/clang/compiler-rt - 0002-Simplify-cross-compilation.-Don-t-use-native-compile.patc

#sdk

Hi , I got following error , try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages How we can use allowerasing through command ,

#sdk