[OE-core] [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux

[Richard Purdie]

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