On Wed, 2017-12-13 at 10:45 +0800, Robert Yang wrote: > Fixed: > MACHINE = "qemux86-64" > require conf/multilib.conf > MULTILIBS = "multilib:lib32" > DEFAULTTUNE_virtclass-multilib-lib32 = "x86" > IMAGE_FSTYPES += "iso" > > $ bitbake lib32-core-image-minimal > ERROR: lib32-core-image-minimal-1.0-r0 do_bootimg: The file > /usr/include/printf.h is installed by both glibc and lib32-glibc, > aborting > > This was because: > lib32-syslinux -> lib32-glibc > virtual/kernel -> glibc > > We can build 64bit syslinux (only build, not install) to fix the > problem, the > do_bootimg only needs several data files of syslinux such as > vesamenu.c32, > these files are not arch related.
Hi Robert, I've been thinking about this one and I'm not 100% convinced this is the right thing to do. When we build "lib32-core-image-minimal", one of the things we want to avoid is building two different toolchains, there should only be one needed for this image. If there is a dependency on "syslinux", that will need the non-multilib toolchain. I suspect that is why libX-syslinux was used as a dependency. Also, there are some things which never make sense as a multilib, the kernel is one example and I'm starting to wonder if syslinux would be another. In the kernel (and kernel module) case we'd provide all the libX variants from the same recipe, we may want to do that for syslinux. It may be we can't avoid the multiple compiler issue and the current codebase may not do so, I think currently we can avoid multiple glibc though. Regardless, I do think this needs a little more thought, we also need better multiple test cases as we're not catching issues like this. I think this needs to be revisited along with your outstanding multilib patch series which I haven't found the time to review yet (sorry). Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
