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

[Hatle, Mark]

Sorry to reply to myself but I forgot one thing..



On Apr 7, 2011, at 10:05 AM, "Hatle, Mark" <mark.hatle at windriver.com> wrote:

> 
> 
> 
> 
> On Apr 7, 2011, at 9:53 AM, "Colin Walters" <walters at verbum.org> wrote:
> 
>> 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):
>> 
> 
> The needs for the arm case include both executables and libraries.  The processor feature can be used, but that only covers the libraries themselves.  We want a mechanism to say that the whole system is built thumb2, except for a particular compilation modules, library and/or application.  (generally is done on a full recipe basis, and not on a single compilation module..)
> 

>From an RPM perspective the real difference is that one type uses multiple recipe builds and let's install time policy decide what to install.. (this is the multilib mentioned above)

The ARM case I mentioned is really optimization based.. There are a few key components like gcc that need to be configured for the multiple types of systems, but the decision on what to install (a.k.a. What special optimizations are required) are made at recipe compile time.

This is why they're related cases, we need a common way to specify these multiple library type optimization and configuration flags... But the eventual result install-time vs compile-time is what makes them different.

> The other issue on ARM embedded systems is that the processor feature approach typically makes the system larger, by providing both the lesser optimized and more completely optimized libraries....  I've had resistence to this approach from customer over that reason.  (mind you I'm in favor of making that easier to use in OE as well.)
> 
>> $ 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)
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky