perf: nativesdk

perf: nativesdk

[Andrej Valek]

Hello,

I know, that what I'm doing is not fully supported way, but... . I 
wanted to build the perf for target device (aarch64), record the data 
and analyze them on the host. So I extended the recipe by adding 
BBCLASSEXTEND = "native nativesdk".

After that I have compilation failure do to missing manifest.

ERROR: nativesdk-perf-1.0-r0 do_configure: The sstate manifest for task 
'linux-libc-headers:populate_sysroot' (multilib variant '') could not be 
found.
The pkgarchs considered were: machineA, cortexa53, cortexa53, cortexa53, 
armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk.
But none of these manifests exists:
/home/build/tmp/sstate-control/manifest-machineA-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-armv8a-crc-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-armv8a-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-aarch64-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-allarch-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-linux-libc-headers.populate_sysroot

The "linux-libc-headers" dependency is coming from "gcc-cross-aarch64".

EXTRADEPENDS = ""
DEPENDS = "virtual/${TARGET_PREFIX}binutils ${EXTRADEPENDS} ${NATIVEDEPS}"
PROVIDES = "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}g++"
python () {
     if d.getVar("TARGET_OS").startswith("linux"):
         d.setVar("EXTRADEPENDS", "linux-libc-headers")
}

This function adds the dependency without respecting any 
native/nativesdk variant.

I know touching the "PACKAGE_EXTRA_ARCHS" or removing this function 
above it's not right way to fix it.

How to deal with something like that?

Thanks,
Andy

Re: [OE-core] perf: nativesdk

[Alexander Kanavin]

On Thu, 19 Jun 2025 at 09:53, Andrej Valek via lists.openembedded.org
<andrej.v=skyrain.eu@lists.openembedded.org> wrote:
> I know, that what I'm doing is not fully supported way, but... . I
> wanted to build the perf for target device (aarch64), record the data
> and analyze them on the host. So I extended the recipe by adding
> BBCLASSEXTEND = "native nativesdk".

If you want to run perf natively, just 'native' should be enough for a
start, no?

Alex

Re: [OE-core] perf: nativesdk

[Andrej Valek]

Hi Alex,

maybe I have to do some more tuning, but what I did:
BBCLASSEXTEND = "native nativesdk"
DEPENDS:remove:class-native = "virtual/${MLPREFIX}libc"

then I run: "bitbake perf-native" and I have the same issue:

ERROR: perf-native-1.0-r0 do_configure: The sstate manifest for task 
'linux-libc-headers:populate_sysroot' (multilib variant '') could not be 
found.
The pkgarchs considered were: machineA, cortexa53, cortexa53, 
armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk.
But none of these manifests exists:
     
/home/build/tmp/sstate-control/manifest-machineA-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-armv8a-crc-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-armv8a-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-aarch64-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-allarch-linux-libc-headers.populate_sysroot
/home/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-linux-libc-headers.populate_sysroot

So nope, it's not working.

Other option is to use perf from host system, but not sure if it's while 
it has completely different options.

BR,
Andy

On 19.06.2025 09:56, Alexander Kanavin via lists.openembedded.org wrote:
> On Thu, 19 Jun 2025 at 09:53, Andrej Valek via lists.openembedded.org
> <andrej.v=skyrain.eu@lists.openembedded.org> wrote:
>> I know, that what I'm doing is not fully supported way, but... . I
>> wanted to build the perf for target device (aarch64), record the data
>> and analyze them on the host. So I extended the recipe by adding
>> BBCLASSEXTEND = "native nativesdk".
> If you want to run perf natively, just 'native' should be enough for a
> start, no?
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#219056): https://lists.openembedded.org/g/openembedded-core/message/219056
> Mute This Topic: https://lists.openembedded.org/mt/113722107/3619876
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [andrej.v@skyrain.eu]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] perf: nativesdk

[Alexander Kanavin]

On Thu, 19 Jun 2025 at 10:07, Andrej Valek <andrej.v@skyrain.eu> wrote:
> maybe I have to do some more tuning, but what I did:
> BBCLASSEXTEND = "native nativesdk"
> DEPENDS:remove:class-native = "virtual/${MLPREFIX}libc"
>
> then I run: "bitbake perf-native" and I have the same issue:
>
> ERROR: perf-native-1.0-r0 do_configure: The sstate manifest for task
> 'linux-libc-headers:populate_sysroot' (multilib variant '') could not be
> found.
> The pkgarchs considered were: machineA, cortexa53, cortexa53,
> armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk.
> But none of these manifests exists:
>
> /home/build/tmp/sstate-control/manifest-machineA-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-armv8a-crc-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-armv8a-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-aarch64-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-allarch-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-linux-libc-headers.populate_sysroot
>
> So nope, it's not working.

It seems as though perf recipe depends on the kernel sources too, so
as it stands, you can't build it natively. I'd directly eliminate the
target deps (e.g. actually remove them from the recipe, as an
experiment) and see how far you get with bitbake perf-native.

Alex

RE: [OE-core] perf: nativesdk

[Marko, Peter]

What you want to do is not really possible.
Perf recipe does not have its own sources, it only copies sources from kernel and then builds them.
And you cannot depend on target recipe (kernel) in native recipe (perf-native).

Also I doubt that perf supports cross-build, meaning analyzing ARM processor counters on x86.
You may have to match your native host machine with target device maybe to point of exact processor type, not only architecture type.

Peter

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Alexander Kanavin via
> lists.openembedded.org
> Sent: Thursday, June 19, 2025 10:13
> To: Andrej Valek <andrej.v@skyrain.eu>
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] perf: nativesdk
> 
> On Thu, 19 Jun 2025 at 10:07, Andrej Valek <andrej.v@skyrain.eu> wrote:
> > maybe I have to do some more tuning, but what I did:
> > BBCLASSEXTEND = "native nativesdk"
> > DEPENDS:remove:class-native = "virtual/${MLPREFIX}libc"
> >
> > then I run: "bitbake perf-native" and I have the same issue:
> >
> > ERROR: perf-native-1.0-r0 do_configure: The sstate manifest for task
> > 'linux-libc-headers:populate_sysroot' (multilib variant '') could not be
> > found.
> > The pkgarchs considered were: machineA, cortexa53, cortexa53,
> > armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk.
> > But none of these manifests exists:
> >
> > /home/build/tmp/sstate-control/manifest-machineA-linux-libc-
> headers.populate_sysroot
> > /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-
> headers.populate_sysroot
> > /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-
> headers.populate_sysroot
> > /home/build/tmp/sstate-control/manifest-armv8a-crc-linux-libc-
> headers.populate_sysroot
> > /home/build/tmp/sstate-control/manifest-armv8a-linux-libc-
> headers.populate_sysroot
> > /home/build/tmp/sstate-control/manifest-aarch64-linux-libc-
> headers.populate_sysroot
> > /home/build/tmp/sstate-control/manifest-allarch-linux-libc-
> headers.populate_sysroot
> > /home/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-linux-libc-
> headers.populate_sysroot
> >
> > So nope, it's not working.
> 
> It seems as though perf recipe depends on the kernel sources too, so
> as it stands, you can't build it natively. I'd directly eliminate the
> target deps (e.g. actually remove them from the recipe, as an
> experiment) and see how far you get with bitbake perf-native.
> 
> Alex

Re: [OE-core] perf: nativesdk

[Andrej Valek]

[-- Attachment #1: Type: text/plain, Size: 5563 bytes --]

Thanks for pointing me out to the right direction.

Yes, I know, that the perf sources are coming directly from kernel. So

> It seems as though perf recipe depends on the kernel sources too, so
> as it stands, you can't build it natively. I'd directly eliminate the
> target deps (e.g. actually remove them from the recipe, as an
> experiment) and see how far you get with bitbake perf-native.

is not possible. But anyway, at the begging I was going with the wrong 
direction. But yes, once I commented-out the section in gcc-cross, I was 
able to compile a nativesdk- variant,

file perf
perf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked, interpreter 
/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-hiltisdk-linux/lib/ld-linux-x86-64.so.2, 
BuildID[sha1]=34bfdb0e321eae26426e45c78c29f63e73ee62d4, for GNU/Linux 
3.2.0, with debug_info, not stripped

but didn't invest more time in tuning or execution.

> Also I doubt that perf supports cross-build, meaning analyzing ARM processor counters on x86.
> You may have to match your native host machine with target device maybe to point of exact processor type, not only architecture type.

I know, that this has to be matching due to ABI, unwinding and so on... 
. On the other hand, if I didn't have confirmation, that x86 could in 
some modes understand arm64 counters I didn't go in this direction.

x86_64 x86_64 x86_64 GNU/Linux variant of perf
perf script -i perf.data --symfs rootfs
unwind: target platform=arm64 is not supported
   systemd-logind     339    65.306223:          1 cycles:P: 
ffff80008007ff30 [unknown] ([kernel.kallsyms])
   systemd-logind     339    65.306230:          1 cycles:P: 
ffff80008007ff30 [unknown] ([kernel.kallsyms])

So yes, script or inject modes can do some stuff. So I wanted to use the 
perf binary directly from Yocto and not from host.

Anyway as I mentioned, I found a correct usable way.
Use qemu-aarch64 for arm binary execution, pass some args and voila:
   systemd-logind     341    43.234008:        711 cycles:P: 
ffff80008007ff30 finish_task_switch.isra.0+0x90 ([kernel.kallsyms])
   systemd-logind     341    43.234016:        711 cycles:P: 
ffff80008007ff30 finish_task_switch.isra.0+0x90 ([kernel.kallsyms])
   systemd-logind     341    43.234020:        711 cycles:P: 
ffff80008007ff30 finish_task_switch.isra.0+0x90 ([kernel.kallsyms])

It can fully unwind the stack... .

BR,
Andy

On 19.06.2025 10:59, Peter Marko via lists.openembedded.org wrote:
> What you want to do is not really possible.
> Perf recipe does not have its own sources, it only copies sources from kernel and then builds them.
> And you cannot depend on target recipe (kernel) in native recipe (perf-native).
>
> Also I doubt that perf supports cross-build, meaning analyzing ARM processor counters on x86.
> You may have to match your native host machine with target device maybe to point of exact processor type, not only architecture type.
>
> Peter
>
>> -----Original Message-----
>> From:openembedded-core@lists.openembedded.org <openembedded-
>> core@lists.openembedded.org> On Behalf Of Alexander Kanavin via
>> lists.openembedded.org
>> Sent: Thursday, June 19, 2025 10:13
>> To: Andrej Valek<andrej.v@skyrain.eu>
>> Cc:openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] perf: nativesdk
>>
>> On Thu, 19 Jun 2025 at 10:07, Andrej Valek<andrej.v@skyrain.eu> wrote:
>>> maybe I have to do some more tuning, but what I did:
>>> BBCLASSEXTEND = "native nativesdk"
>>> DEPENDS:remove:class-native = "virtual/${MLPREFIX}libc"
>>>
>>> then I run: "bitbake perf-native" and I have the same issue:
>>>
>>> ERROR: perf-native-1.0-r0 do_configure: The sstate manifest for task
>>> 'linux-libc-headers:populate_sysroot' (multilib variant '') could not be
>>> found.
>>> The pkgarchs considered were: machineA, cortexa53, cortexa53,
>>> armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk.
>>> But none of these manifests exists:
>>>
>>> /home/build/tmp/sstate-control/manifest-machineA-linux-libc-
>> headers.populate_sysroot
>>> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-
>> headers.populate_sysroot
>>> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-
>> headers.populate_sysroot
>>> /home/build/tmp/sstate-control/manifest-armv8a-crc-linux-libc-
>> headers.populate_sysroot
>>> /home/build/tmp/sstate-control/manifest-armv8a-linux-libc-
>> headers.populate_sysroot
>>> /home/build/tmp/sstate-control/manifest-aarch64-linux-libc-
>> headers.populate_sysroot
>>> /home/build/tmp/sstate-control/manifest-allarch-linux-libc-
>> headers.populate_sysroot
>>> /home/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-linux-libc-
>> headers.populate_sysroot
>>> So nope, it's not working.
>> It seems as though perf recipe depends on the kernel sources too, so
>> as it stands, you can't build it natively. I'd directly eliminate the
>> target deps (e.g. actually remove them from the recipe, as an
>> experiment) and see how far you get with bitbake perf-native.
>>
>> Alex
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#219062):https://lists.openembedded.org/g/openembedded-core/message/219062
>> Mute This Topic:https://lists.openembedded.org/mt/113722107/3619876
>> Group Owner:openembedded-core+owner@lists.openembedded.org
>> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [andrej.v@skyrain.eu]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

[-- Attachment #2: Type: text/html, Size: 9089 bytes --]

Re: [OE-core] perf: nativesdk

[Richard Purdie]

On Thu, 2025-06-19 at 09:53 +0200, Andrej Valek via lists.openembedded.org wrote:
> I know, that what I'm doing is not fully supported way, but... . I 
> wanted to build the perf for target device (aarch64), record the data
> and analyze them on the host. So I extended the recipe by adding 
> BBCLASSEXTEND = "native nativesdk".
> 
> After that I have compilation failure do to missing manifest.
> 
> ERROR: nativesdk-perf-1.0-r0 do_configure: The sstate manifest for task 
> 'linux-libc-headers:populate_sysroot' (multilib variant '') could not be 
> found.
> The pkgarchs considered were: machineA, cortexa53, cortexa53, cortexa53, 
> armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk.
> But none of these manifests exists:
> /home/build/tmp/sstate-control/manifest-machineA-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-armv8a-crc-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-armv8a-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-aarch64-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-allarch-linux-libc-headers.populate_sysroot
> /home/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-linux-libc-headers.populate_sysroot
> 
> The "linux-libc-headers" dependency is coming from "gcc-cross-aarch64".
> 
> EXTRADEPENDS = ""
> DEPENDS = "virtual/${TARGET_PREFIX}binutils ${EXTRADEPENDS} ${NATIVEDEPS}"
> PROVIDES = "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}g++"
> python () {
>      if d.getVar("TARGET_OS").startswith("linux"):
>          d.setVar("EXTRADEPENDS", "linux-libc-headers")
> }
> 
> This function adds the dependency without respecting any 
> native/nativesdk variant.
> 
> I know touching the "PACKAGE_EXTRA_ARCHS" or removing this function 
> above it's not right way to fix it.
> 
> How to deal with something like that?

Ignoring this is all a bad idea, something which is nativesdk should be
using gcc-crosssdk, not gcc-cross. gcc-cross quite correctly depends on
linux-libc-headers, gcc-crosssdk will depend on nativesdk-linux-libc-
headers.

Cheers,

Richard

Re: [OE-core] perf: nativesdk

[Andrej Valek]

Hi Richard,

Yes I know, that is bad, but I solved it already with other way.

On the other hand, maybe the lines in kernel-yocto.bbclass should be 
target specific.

do_kernel_configme[depends] += 
"virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
do_kernel_configme[depends] += 
"virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"

I think, that dependency to gcc-cross was done like:

linux[do_kernel_configme] -> gcc-cross-aarch64 -> linux-libc-headers.

BR,
Andy


On 19.06.2025 13:21, Richard Purdie via lists.openembedded.org wrote:
> On Thu, 2025-06-19 at 09:53 +0200, Andrej Valek via lists.openembedded.org wrote:
>> I know, that what I'm doing is not fully supported way, but... . I
>> wanted to build the perf for target device (aarch64), record the data
>> and analyze them on the host. So I extended the recipe by adding
>> BBCLASSEXTEND = "native nativesdk".
>>
>> After that I have compilation failure do to missing manifest.
>>
>> ERROR: nativesdk-perf-1.0-r0 do_configure: The sstate manifest for task
>> 'linux-libc-headers:populate_sysroot' (multilib variant '') could not be
>> found.
>> The pkgarchs considered were: machineA, cortexa53, cortexa53, cortexa53,
>> armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk.
>> But none of these manifests exists:
>> /home/build/tmp/sstate-control/manifest-machineA-linux-libc-headers.populate_sysroot
>> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
>> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
>> /home/build/tmp/sstate-control/manifest-cortexa53-linux-libc-headers.populate_sysroot
>> /home/build/tmp/sstate-control/manifest-armv8a-crc-linux-libc-headers.populate_sysroot
>> /home/build/tmp/sstate-control/manifest-armv8a-linux-libc-headers.populate_sysroot
>> /home/build/tmp/sstate-control/manifest-aarch64-linux-libc-headers.populate_sysroot
>> /home/build/tmp/sstate-control/manifest-allarch-linux-libc-headers.populate_sysroot
>> /home/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-linux-libc-headers.populate_sysroot
>>
>> The "linux-libc-headers" dependency is coming from "gcc-cross-aarch64".
>>
>> EXTRADEPENDS = ""
>> DEPENDS = "virtual/${TARGET_PREFIX}binutils ${EXTRADEPENDS} ${NATIVEDEPS}"
>> PROVIDES = "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}g++"
>> python () {
>>       if d.getVar("TARGET_OS").startswith("linux"):
>>           d.setVar("EXTRADEPENDS", "linux-libc-headers")
>> }
>>
>> This function adds the dependency without respecting any
>> native/nativesdk variant.
>>
>> I know touching the "PACKAGE_EXTRA_ARCHS" or removing this function
>> above it's not right way to fix it.
>>
>> How to deal with something like that?
> Ignoring this is all a bad idea, something which is nativesdk should be
> using gcc-crosssdk, not gcc-cross. gcc-cross quite correctly depends on
> linux-libc-headers, gcc-crosssdk will depend on nativesdk-linux-libc-
> headers.
>
> Cheers,
>
> Richard
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#219068): https://lists.openembedded.org/g/openembedded-core/message/219068
> Mute This Topic: https://lists.openembedded.org/mt/113722107/3619876
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [andrej.v@skyrain.eu]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] perf: nativesdk

[Richard Purdie]

On Thu, 2025-06-19 at 13:44 +0200, Andrej Valek wrote:
> Yes I know, that is bad, but I solved it already with other way.
> 
> On the other hand, maybe the lines in kernel-yocto.bbclass should be 
> target specific.
> 
> do_kernel_configme[depends] += 
> "virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
> do_kernel_configme[depends] += 
> "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
> 
> I think, that dependency to gcc-cross was done like:
> 
> linux[do_kernel_configme] -> gcc-cross-aarch64 -> linux-libc-headers.

It won't be those. kernel.bbclass does:

DEPENDS += "virtual/cross-binutils virtual/cross-cc kmod-native bc-native bison-native"
[...]
# we include gcc above, we dont need virtual/libc
INHIBIT_DEFAULT_DEPS = "1"

and virtual/cross-cc will expand to gcc-cross-aarch64.

There is an assumption that nobody uses nativesdk with kernel.bbclass
in multiple places.

Cheers,

Richard

Re: [OE-core] perf: nativesdk

[Andrej Valek]

Ok, then forget about the previous variant, since I have a solution 
here: https://lists.openembedded.org/g/openembedded-core/message/219066 
. I will just ship qemu-native in SDK.

But anyway thanks for your response.
Andrej

On 19.06.2025 14:45, Richard Purdie via lists.openembedded.org wrote:
> On Thu, 2025-06-19 at 13:44 +0200, Andrej Valek wrote:
>> Yes I know, that is bad, but I solved it already with other way.
>>
>> On the other hand, maybe the lines in kernel-yocto.bbclass should be
>> target specific.
>>
>> do_kernel_configme[depends] +=
>> "virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
>> do_kernel_configme[depends] +=
>> "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot"
>>
>> I think, that dependency to gcc-cross was done like:
>>
>> linux[do_kernel_configme] -> gcc-cross-aarch64 -> linux-libc-headers.
> It won't be those. kernel.bbclass does:
>
> DEPENDS += "virtual/cross-binutils virtual/cross-cc kmod-native bc-native bison-native"
> [...]
> # we include gcc above, we dont need virtual/libc
> INHIBIT_DEFAULT_DEPS = "1"
>
> and virtual/cross-cc will expand to gcc-cross-aarch64.
>
> There is an assumption that nobody uses nativesdk with kernel.bbclass
> in multiple places.
>
> Cheers,
>
> Richard
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#219073): https://lists.openembedded.org/g/openembedded-core/message/219073
> Mute This Topic: https://lists.openembedded.org/mt/113722107/3619876
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [andrej.v@skyrain.eu]
> -=-=-=-=-=-=-=-=-=-=-=-
>