what is the long-term plan for YP and eglibc?

what is the long-term plan for YP and eglibc?

[Robert P. J. Day]

  at the YP resources page for eglibc:

https://www.yoctoproject.org/tools-resources/projects/eglibc

one reads:

"The Yocto Project encourages interested parties to get involved with
the EGLIBC project. More information is at http://eglibc.org."

  but following that link, one learns:

"EGLIBC is no longer developed and such goals are now being addressed
directly in GLIBC."

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: what is the long-term plan for YP and eglibc?

[Paul Eggleton]

Hi Robert,

On Friday 01 August 2014 05:38:07 Robert P. J. Day wrote:
>   at the YP resources page for eglibc:
> 
> https://www.yoctoproject.org/tools-resources/projects/eglibc
> 
> one reads:
> 
> "The Yocto Project encourages interested parties to get involved with
> the EGLIBC project. More information is at http://eglibc.org."

That might now be out of date in view of upstream developments.

>   but following that link, one learns:
> 
> "EGLIBC is no longer developed and such goals are now being addressed
> directly in GLIBC."

The long-term (even medium-term) plan is to switch back to glibc. We do still 
rely on some of the functionality in eglibc that hasn't been incorporated back 
into glibc though, e.g. poky-tiny uses eglibc's fine-grained component 
selection, so it's not necessarily a straightforward switch. Mostly I think 
we're waiting on some of Khem's (and probably other folks) time to sort this 
out.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: what is the long-term plan for YP and eglibc?

[Khem Raj]

On Fri, Aug 1, 2014 at 2:53 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi Robert,
>
> On Friday 01 August 2014 05:38:07 Robert P. J. Day wrote:
>>   at the YP resources page for eglibc:
>>
>> https://www.yoctoproject.org/tools-resources/projects/eglibc
>>
>> one reads:
>>
>> "The Yocto Project encourages interested parties to get involved with
>> the EGLIBC project. More information is at http://eglibc.org."
>
> That might now be out of date in view of upstream developments.
>
>>   but following that link, one learns:
>>
>> "EGLIBC is no longer developed and such goals are now being addressed
>> directly in GLIBC."
>
> The long-term (even medium-term) plan is to switch back to glibc. We do still
> rely on some of the functionality in eglibc that hasn't been incorporated back
> into glibc though, e.g. poky-tiny uses eglibc's fine-grained component
> selection, so it's not necessarily a straightforward switch. Mostly I think
> we're waiting on some of Khem's (and probably other folks) time to sort this
> out.


The eglibc has had its last release in 2.19 and btw. the release
branches in eglibc will get backports and fixes
as long as corresponding glibc branches are open. As of now eglibc
trunk has ceased to exist. I am waiting on 2.20 glibc release (which
should be happening anytime now)
there is a list of changed in eglibc that are not in glibc the reason
being no one carried them forward and partly I am also  to blame due
to time constraints but I will make up for it :)

- ppc/e500 has few changes around SPE which our FSL/ppc bsp might care
- Option group support - As Paul mentioned we use it and I plan to
forward port it and possibly submit it for 2.21
- cross-localedef - We care about it. We have to see whats missing in
2.20 and forward port the missing parts.
- cross testing - There are minor adoptions needed but we dont have
ptests for eglibc yet so this should be minor

Rest of items which are left out doesn't bother us.

We are in August. I am hoping that we can include 2.20 in 1.7 release
but there might be a risk associated due to above
and that we will change recipes to be called glibc instead of eglibc
some metadata changes have to be made as well. I hope to work on it
starting second week of august.

Hope that helps
-Khem