Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Robert Yang <liezhi.yang@windriver.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux
Date: Wed, 03 Jan 2018 12:43:20 +0000	[thread overview]
Message-ID: <1514983400.5525.137.camel@linuxfoundation.org> (raw)
In-Reply-To: <e911950fbee39af9c5889c41872f2f77f94cc9c1.1513133105.git.liezhi.yang@windriver.com>

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


  reply	other threads:[~2018-01-03 12:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-13  2:45 [PATCH 0/2] fix multilib + iso Robert Yang
2017-12-13  2:45 ` [PATCH 1/2] image-live.bbclass: add MLPREFIX to core-image-minimal-initramfs Robert Yang
2017-12-13  2:45 ` [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux Robert Yang
2018-01-03 12:43   ` Richard Purdie [this message]
2018-01-03 13:56     ` Robert Yang
2018-01-03 14:19       ` Richard Purdie
2018-01-04 11:13         ` Robert Yang
2018-01-08 11:22           ` Robert Yang
2018-01-09  1:45           ` Robert Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1514983400.5525.137.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=liezhi.yang@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox