> On Sep 15, 2016, at 10:04 PM, Josias Inacio da Silva Filho > <josiasina...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
