[OE-core] [poky] Proposed Multilib Implementation Brainstorming

[Koen Kooi]

Op 7 apr 2011, om 18:53 heeft Colin Walters het volgende geschreven:

> On Thu, Apr 7, 2011 at 12:10 PM, Hatle, Mark <mark.hatle at windriver.com> wrote:
>> 
>> I think definition may be an issue here.  When I speak of multilibs I am talking primarily about multiliple non-conflicting, ABI incompatible libraries being installed at the same time.  This is the ELF 32 and ELF 64 case where the items can't be linked together, but can be installed and jrun on the same machine.
> 
> Right, that's "multilib".
> 
>> The alternative is the case on ARM where we have one single ABI but multiple ways to implement the code.. Thumb, neon, vfp, etc being options.  We want to do this as well, but while related, I see it as a diffent use case.
> 
> Isn't this already covered by glibc's support for
> /lib/$processor_feature?  On my Fedora 14 x86_64 system I have
> /lib/i686/nosegneg for example, and a simple "strace true" shows us
> trying to find a variant of libc that is built for TLS (and not
> finding it):
> 
> $ strace true
> execve("/bin/true", ["true"], [/* 54 vars */]) = 0
> brk(0)                                  = 0xe59000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f54472b0000
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
> open("/src/build/jhbuild/lib64/tls/x86_64/libc.so.6", O_RDONLY) = -1
> ENOENT (No such file or directory)

That's what I call 'hwcap'. OE currently lacks a decent way to build and install the permuations people want. For armv7a this boils down to NEON/VENUM or not, TI, Freescale and Qualcomm have it, Nvidia and Marvell don't.
This type of setup on ARM is only usefull for people who think that one rootfs to rule all boards is the best thing since sliced bread. It does make it really easy to hand people a rootfs and have it "just work" and not get caught in "why didn't you license NEON?" debates :)

regards,

Koen