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? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] use native (cross) toolchain instead of a populated nativesdk (cross-canadian) toolchain
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? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] use native (cross) toolchain instead of a populated nativesdk (cross-canadian) toolchain
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, so 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 works very good for us. Then I am 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 populated 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? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
