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.
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.
Add Mark in the loop, here is his comments:
"""
We had a single toolchain built outside of the Yocto Project environment with a
custom spec file. The only way to do this inside of the Yocto Project would be
to generate a custom spec file for the cross-toolchain based on a specific
configuration.
In the past when this was explored, it was deemed to not be a 'generic'
solution. So using the stock GCC spec file(s) and/or multiple toolchains was
the better generic approach.
"""
So I'm leaning to keep the current status, multiple toolchains for multilib.
// Robert
// 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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
