How to build an SDK toolchain for native x86_64

How to build an SDK toolchain for native x86_64

[Josias Inacio da Silva Filho]

Hi folks,

Here’s my current setup and current situation:

Host: x86_64
Target: aarch64

Build core-image-base for aarch64 - OK
populate_sdk for aarch64 - OK

My application and it unit tests also gets compiled to aarch64.

What I wanted now would be something like run populate_sdk for “core-image-base-native”. The reason for that is because I want to compile and run my unit tests using my host machine only (x86_64). This makes application development much easier, since I don’t need the target nor QEMU to run the unit tests. And I still want the toolchain to be generated by Yocto since it solves all package dependencies for me.

What I attempted:

1) Create a new “core-image-toolchain-native” similar to core-image-base, but tweaking to be able to build for native. That does not seem to be the right way, I spent a lot of time doing this and got nowhere since many of the image's recipes do not support building with native support.

2) Change my machine type to be qemux86_64, then call “bitbake core-image-base -c populate_sdk”. That would generate a toolchain for x86-64 right? Well it did, and I was able to use this toolchain to compile my unit tests for x86_64. But the problem is that this still assumes that I’ll be running those unit tests on the target machine ( QEMU x86_64), so if I try to run it in my host machine, it complains about some missing dynamic libraries that are only found in the sysroot of the target qemux86_64.

Is there any proper solution for this case?

Re: How to build an SDK toolchain for native x86_64

[Khem Raj]

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


> On Sep 15, 2016, at 10:04 PM, Josias Inacio da Silva Filho <josiasinacio@hotmail.com> wrote:
> 
> Hi folks,
> 
> Here’s my current setup and current situation:
> 
> Host: x86_64
> Target: aarch64
> 
> Build core-image-base for aarch64 - OK
> populate_sdk for aarch64 - OK
> 
> My application and it unit tests also gets compiled to aarch64.
> 
> What I wanted now would be something like run populate_sdk for “core-image-base-native”. The reason for that is because I want to compile and run my unit tests using my host machine only (x86_64). This makes application development much easier, since I don’t need the target nor QEMU to run the unit tests. And I still want the toolchain to be generated by Yocto since it solves all package dependencies for me.
> 
> What I attempted:
> 
> 1) Create a new “core-image-toolchain-native” similar to core-image-base, but tweaking to be able to build for native. That does not seem to be the right way, I spent a lot of time doing this and got nowhere since many of the image's recipes do not support building with native support.
> 
> 2) Change my machine type to be qemux86_64, then call “bitbake core-image-base -c populate_sdk”. That would generate a toolchain for x86-64 right? Well it did, and I was able to use this toolchain to compile my unit tests for x86_64. But the problem is that this still assumes that I’ll be running those unit tests on the target machine ( QEMU x86_64), so if I try to run it in my host machine, it complains about some missing dynamic libraries that are only found in the sysroot of the target qemux86_64.
> 
> Is there any proper solution for this case?

This is not a usecase which SDK is meant for, the SDK is generally meant for doing cross development as you have also
seen above, and why the native case it not covered is also due to fact you explained above where you see some missing
libraries. Can this be fixed, sure it can, but its a new feature that would require additional considerations if we
have to provide SDK host and cross SDK, this may have usecases but its not so common.

Ideally, you should use the gcc toolchain as installed on your SDK host ( one from ubuntu/debian/fedora whatever distro you use )
and use that for native verification.

You are welcome to file an enhancement request in bugzilla for SDK support for SDK host.
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]