[yocto] 答复: 答复: use native (cross) toolchain instead of a populated nativesdk (cross-canadian) toolchain

[Zhen LiWei]

Yes, I think you are right, the -native sysroot is not designed for people to develop native program upon. Currently my little setup runs well, but to maintain/improve it will be hard.

eSDK may not be an option for now. So later I think I will try the qemu-x86-64 target to keep a more maintainable identical (to real target) ENV for the “native” programs---but still need some tricks since people are used to running emulated test directly. So I will manage to run our qemu based apps directly from the build machine: manipulating .interp and rpath/LD_LIBARARY_PATH should do, and I had some positive result before. So this should be a more reliable idea than the native “x86-64_linux” sysroot.

Thanks again,
Liwei

________________________________
发件人: ChenQi <Qi.Chen at windriver.com>
发送时间: Monday, November 13, 2017 1:41:38 PM
收件人: Zhen LiWei; yocto at yoctoproject.org
主题: Re: 答复: [yocto] use native (cross) toolchain instead of a populated nativesdk (cross-canadian) toolchain

On 11/13/2017 09:44 AM, Zhen LiWei wrote:
Thank you. The SDK installing host being different is actually not our concern: we have some strict definition of what host distro we should use when using the SDK.

And basically the native toolchain works rather fine. And I can (I think) use it with some confidence.

The other goal of mine---using the x86_64_linux sysroot to develop x86 native programs---however, is difficult. For 1) Quite some patches needed for autotools, pkg-config, etc…. 2) basic libraries like openssl need to co-exist with the host-distro-native ones, so when building binaries upon them I need to be very careful (ly manipulating the pkg-config, xxx-config, and rpathes). 3) various in-house and 3rdparty binaries need to be built on this complex setup, which use different config/build infrastructures.

So basically this is not how the native sysroot is intended to be used (but in the BB env it is controled very well: every native package can be built in it). So I need to continue to improve my procedure, or just give it up and use a qemu image instead.

Liwei


From previous emails, I can see that your major concern is about SDK and application development. And you want to keep SDK in sync across different hosts.
eSDK and devtool in new Yocto releases are designed to solve such problems.
I'd suggest you take a look at these tools if you are interested.

P.S. From my experience, if you make custom scripts to wrapper yocto projects, you should keep things as simple as possible. Otherwise, there would be a lot of work when you want to use new yocto releases.

Best Regards,
Chen Qi

________________________________
发件人: ChenQi <Qi.Chen at windriver.com><mailto:Qi.Chen at windriver.com>
发送时间: Thursday, November 9, 2017 10:48:41 AM
收件人: Zhen LiWei; yocto at yoctoproject.org<mailto:yocto at yoctoproject.org>
主题: Re: [yocto] use native (cross) toolchain instead of a populated nativesdk (cross-canadian) toolchain

If I understand it correctly, you are talking about using native components directly for SDK.
If you are using all the same machine with the same OS, you could use native components directly, maybe with a little modification.
But in fact, the host where SDK is installed might be different from the host where SDK is built.
Check the SDKMACHINE variable.

Best Regards,
Chen Qi

On 11/07/2017 11:09 PM, Zhen LiWei wrote:

Hi, I am working on a yocto 2.0 based distro and we usually populate_sdk and use the toolchain included in SDK.



But we also like to check the SDK into a SVN repo, and checkout it anywhere, and use it away right where it is checked out. And since the nativesdk binaries are based on a different glibc than native, and have the “dynamic loader” path hardcoded in them, I have to patch the toolchain binaries’ .interp secion to point to a common place, and update the loader into that common place automatically in some way. Other than this, things work very good for us.



Then I was thinking: is it a good practice, to use the native/cross toolchain directly from the tmp/sysroots/x86_64-native folder. I tried and succeeded, by just moving the sysroot to where the checked-out nativesdk toolchain was.



An extra bonus about this is that we got a more populated sysroot for native platform too, for example a openssl dev package at the same version as that on target, that we can actually use to make the native platform a closer-to-target dev env for some “workbench” build.



However I’m still wondering: is there any thing negative about this style? One thing known is that the SDK-using host need to be similar to the SDK-building host, but that is not an issue for us. But anything else, guys?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171115/9f74a4ed/attachment.html>