As of http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e153efde9754a650e555f46cba09680baabd7d7e, the populate_sdk and polulate_sdk_ext tasks have been deleted for lib32-IMAGE. This seems to cause regression as we no longer have an easy way to generate SDK with pure 32 bit userland. Here's some complaints from Yocto mailing list. """ I have a hard time understanding how to build a distro with x86_64 kernel, i586 userland and an SDK for that. In the beginning I assumed and have been told on IRC that multilib is the way to go. But it seems that building and SDK is currently broken/disabled: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e153efde9754a650e555f46cba09680baabd7d7e """ Looking at the error message mentioned in the commit, I guess it's caused by manifest sharing. In particular, lines below in multilib.conf seem unnecessary and problematic for me. STAGING_DIR_HOST = "${WORKDIR}/${MLPREFIX}recipe-sysroot" STAGING_DIR_TARGET = "${WORKDIR}/${MLPREFIX}recipe-sysroot" RECIPE_SYSROOT = "${WORKDIR}/${MLPREFIX}recipe-sysroot" Robert, Ross and Richard, what do you think of this issue? Best Regards, Chen Qi
If you bitbake X-image -c populate_sdk, you get an sdk with both toolchains in it. It would be the same sdk that you'd get if did bitbake lix32-X-image -c populate_sdk. I'm therefore not sure there is a problem to be solved here?
I think the major concern here is about development packages like ncurses-dev, lib32-ncurses-dev, etc. Say ImageA contains ncurses, SDK generated via `bitbake ImageA -c populate_sdk' could be used for development against ncurses, but not lib32-ncurses; while previous SDK generated via `bitbake lib32-ImageA -c populate_sdk' could be used for development against lib32-ncurses. Currently we have to manually add 'lib32-ncurses' to the image and generate the SDK again to cover the above use case. But for projects having quite a few dependencies, this is not convenient.
(In reply to comment #2) > I think the major concern here is about development packages like > ncurses-dev, lib32-ncurses-dev, etc. > > Say ImageA contains ncurses, SDK generated via `bitbake ImageA -c > populate_sdk' could be used for development against ncurses, but not > lib32-ncurses; while previous SDK generated via `bitbake lib32-ImageA -c > populate_sdk' could be used for development against lib32-ncurses. > > Currently we have to manually add 'lib32-ncurses' to the image and generate > the SDK again to cover the above use case. > > But for projects having quite a few dependencies, this is not convenient. I think you do have a point here but it isn't really clear in a mutlilib configuration which dev-pkgs should be installed, the "normal" ones, the "other libXX ones, or both? It probably comes down to user configuration.
(In reply to comment #3) > (In reply to comment #2) > > I think the major concern here is about development packages like > > ncurses-dev, lib32-ncurses-dev, etc. > > > > Say ImageA contains ncurses, SDK generated via `bitbake ImageA -c > > populate_sdk' could be used for development against ncurses, but not > > lib32-ncurses; while previous SDK generated via `bitbake lib32-ImageA -c > > populate_sdk' could be used for development against lib32-ncurses. > > > > Currently we have to manually add 'lib32-ncurses' to the image and generate > > the SDK again to cover the above use case. > > > > But for projects having quite a few dependencies, this is not convenient. > > I think you do have a point here but it isn't really clear in a mutlilib > configuration which dev-pkgs should be installed, the "normal" ones, the > "other libXX ones, or both? It probably comes down to user configuration. I totally agree. In fact, user experience, or in other words, how users are making use of the project, is what I care about. For multilib, I think there are mainly two use cases. 1) 64bit userspace + some 32bit libraries 2) pure 32bit userspace Use case 1) is the usual use case. I did have doubts whether people still need 2) nowadays. Robert once told me that there did exist users who want 2). And from what I know, Kai's multilib & allarch patches, apart from its side effects, are mainly for 2). But I didn't ever get any direct feedback from users who use 2), so I still doubted whether there are users who use 2). That's why when some user complaint about the newly released thud about lacking direct SDK support for 2), I quickly filed a bug. The current status is, we have ImageA, and corresponding SDK; we have lib32-ImageA, but no corresponding SDK. Users need to do the following if they want a working lib32 image and SDK. IMAGE_INSTALL_append = " lib32-libA lib32-libB ..." `bitbake lib32-ImageA' `bitbake ImageA -c populate_sdk' (Note that in the above step, 64bit binaries are also built.) (Also, not sure if the above steps are documented.) I'm really not sure what we should do. Just as the user replied on the mailing list, the above steps worked for him. So maybe we could just leave things as they are now. Maybe we wait for more use feedbacks? Add Kai and Mark Hatle to the CC list.
Is there actually work to do for his bug? Mark Hatle, perhaps you can review and give your point of view. I'll leave this at 2.8-M1 for now but move it to M2 or later if it does not get closed.
ARM systems are the typical case where we need a way to generate a 32-bit SDK. 64-bit ARM and 32-bit ARM are run-time compatible (they don't clash) but they are not build time compatible. (No shared kernel/glibc/gcc headers.. they -are- different!) So in order to resolve this our customers build two SDKs, one for the 64-bit development and one for 32-bit development. (And yes, they STILL do 32-bit development, primarily due to their own legacy software or other business reasons.) As I see it, the only way to do that right now would be to build a 'fake' machine for the 32-bit case to generate an SDK against. And that will likely cause maintenance problems, trying to keep everything in sync and working -- while trying to make it clear the fake '32-bit' machine isn't actually functional. The whole purpose of the bitbake -c populate_sdk <image> was to make the SDK easy for anyone to create without any specific knowledge of what they were doing. (image in the above is either the image or the multilib variant.)
This change has been there for a long time, people seem to accept it.