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

[Robert Yang]

Hi RP,

On 01/04/2018 07:13 PM, Robert Yang wrote:
> Hi RP,
> 
> Thanks for the reply.
> 
> On 01/03/2018 10:19 PM, Richard Purdie wrote:
>> On Wed, 2018-01-03 at 21:56 +0800, Robert Yang wrote:
>>>> 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.
>>> I think that syslinux is different from kernel, 64bit kernel can
>>> provide 32bit kernel via kernel config, but syslinux can't (except
>>> these non arch files).
>>
>> Think about this differently. The system can ever only boot one single
>> kernel. The image can have several different multilibs running at once
>> in different userspace processes but there can only ever be one running
>> kernel.
>>
>> How that kernel is configured is obviously important but the key thing
>> is there can only be one running.
>>
>> The bootloader is similar in that you likely only ever want one and I
>> suspect syslinux is similar.
> 
> Makes sense, I will work on it.

I tried syslinux, we can make syslinux provide lib32-syslinux, if we treat
it as a bootloader, it is OK since we use syslinux-native to install the
bootloader, but if we treat it as an application, e.g.:

IMAGE_INSTALL += "syslinux"
And then:
bitbake lib32-core-image-minimal

I think that we need a 32bit syslinux to be installed rather than 64bit,
so I'm afraid that we can't let syslinux provide lib32-syslinux.

// Robert

> 
>>
>> Also, don't confuse this with multi-boot or multi partition systems
>> where there could be a "main" and a "backup" kernel. In those cases
>> there would only ever be one running at once.
>>
>>>> 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.
>>> I'm not sure about a problem on this, should lib32-image can run
>>> 64bit programs or not ? If yes, then kernel should be 64bit, and we
>>> can't avoid building 64bit compilers. And I'm leaning to yes since we
>>> call it multilib, the pure 32bit image which can't run 64bit programs
>>> can't be called multilib.
>>
>> That is a configuration issue for the multilib you select. In general,
>> yes you'd want a 64 bit kernel.
>>
>>> I did a rough search on why glibc is built, when bitbake lib32-image,
>>> it is because:
>>>
>>> 64 bit kernel -> gcc-cross-x86_64 -> virtual/${TARGET_PREFIX}libc-
>>> for-gcc,
>>> and the TARGET_PREFIX is x86_64 when building gcc-cross-x86_64,
>>> While the virtual/x86_64-poky-linux-libc-for-gcc is provided by
>>> glibc.
>>>
>>> I tried to remove the depends, both "bitbake gcc-cross-x86_64" and
>>> "bitbake linux-yocto" can be built, but other recipes such as quilt
>>> would be failed:
>>
>> I find it interesting that gcc-cross-x86_64 would build without glibc.
>> If that really is the case we may be able to speed up our compiler
>> bootstrap so that could be worth investigating further.
>>
>> Its not surprising that libgcc won't build without glibc though.
>> Perhaps gcc-cross works since we split out the build of libgcc?
>>
>>>> collect2: error: ld returned 1 exit status
>>>> Makefile:978: recipe for target 'libgcc_s.so' failed
>>> And move virtual/${TARGET_PREFIX}libc-for-gcc to BASE_DEFAULT_DEPS
>>> can't make it work either, so it seems that we can't avoid building
>>> glibc.
>>
>> No, I'd forgotten that gcc-cross depends on glibc. Based on the above
>> there may still be some optimisation we can make here.
>>
>> In the back of my mind, I'm concious that one x86 cross compiler should
>> be able to work for 32 and 64 bit too, its just the compiler options
>> and libgcc etc. would need to be generated for both...
> 
> Build one toolchain for both x86 32 and 64 is possible, I'd like to work
> on it if it is worth.
> 
> // Robert
> 
>>
>>>> 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.
>>>> think this needs to be revisited along with your outstanding
>>>> multilib
>>>> patch series which I haven't found the time to review yet (sorry).
>>> That's all right, I'm very glad to make mutilib work well, including
>>> adding test cases for them. It is nearly broken after changed from
>>> smart + rpm5 to dnf + rpm4, those patches fixed the problem.
>>
>> Agreed, its important and on my list of things to review, I've just had
>> to focus on getting build testing working properly and now I can try
>> and clear some of the patch backlog.
>>
>> Cheers,
>>
>> Richard
>>