[yocto-ab] Fwd: Re: eglibc vs glibc

Wed Dec 18 12:56:48 PST 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks Sean for pointin out that my message went encrypted I was using
a less frequently used machine to reply. Here is forwarded message (
hopefully not crypted this time)

On 12/11/2013 1:53 PM, Hart, Darren wrote:
> On Wed, 2013-12-11 at 21:09 +0000, Richard Purdie wrote:
>> On Wed, 2013-12-11 at 11:59 -0500, William Mills wrote:
>>> From Linaro I understand that eglibc is nearing its last
>>> release. Linaro is planning the transition from eglibc to
>>> glibc. They are asking what gaps remain in glibc that are
>>> important to
eglibc
>>> users. We realize that embedded is the most likely where any
>>> gaps exist. Linaro toolchain builds eglibc but they turn on all
>>> the options so
they
>>> do not have a lot of experience on scaling down.
>>> 
>>> Has oe-core already done or planned the transition to glibc?
>> 
>> It has not done it and the transition is not planned as yet.
>> 
>>> Have we identified any gaps?
>> 
>> The biggest issue is the lack of config options to cut down the
>> size of eglibc.
>> 
>>> Has any one tried yp-tiny with glibc?
>> 
>> No, it won't work due to the issue above.
> 
> An open work item here is to complete research into the limitations
> of uclibc to determine if the granular componentization of eglibc
> is really needed, or if uclibc might be a more appropriate option
> for poky-tiny.

I would say yes thats a good option to consider for tiny systems.

> 
> Alternatively, given the complexity of working with the eglibc
> config options and integrating it into a product, another option
> would be to only make the division at individual libraries and use
> uclibc when truly tiny is required.
> 
> Ultimately, I think this alternative is where we will land.
> Especially if the resources can't be scratched together to do the
> port ourselves.
> 
> My 0.02, for whatever it's worth.
> 
> -- Darren
> 
>> 
>>> Linaro toolchain group is asking if there are any gaps that
>>> need
to be
>>> closed. I don't know enough to guide them.
>> 
>> The discussion was taken upstream:
>> 
>> http://www.eglibc.org/archives/patches/msg01276.html
>> 
>> but they've said no unless someone steps up to do the work. We're
>> kind of in stalemate at the moment as I understand it. Khem or
>> Mark may know more about the current status but I don't think
>> much as changed since those emails.
>> 

The changes w.r.t kconfigs is on our plate yes and I have plans but less
of time towards it lately but I would make sure that it does not get
dropped once eglibc is merged into glibc. Some pieces of this
feature is outside of eglibc at present.

>> Cheers,
>> 
>> Richard
>> 
>> 
>> 
>> 
> 

- -------- Original Message --------
Subject: Re: [yocto-ab] eglibc vs glibc
Date: Wed, 18 Dec 2013 13:53:39 -0600
From: Sean Hudson <sean_hudson at mentor.com>
Organization: Mentor Graphics - Embedded Software Division
To: Khem Raj <raj.khem at gmail.com>

Khem,

  Did you mean to send this to the AB list?  It shows that only Bill and
Darren can decrypt it.

Regards,
     Sean

Sean Hudson | Embedded Linux Architect & Member of Technical Staff
Mentor Graphics – Embedded Systems Division™

On 12/11/2013 09:45 PM, Khem Raj wrote:
> On 12/11/2013 1:53 PM, Hart, Darren wrote:
>> On Wed, 2013-12-11 at 21:09 +0000, Richard Purdie wrote:
>>> On Wed, 2013-12-11 at 11:59 -0500, William Mills wrote:
>>>> From Linaro I understand that eglibc is nearing its last
>>>> release. Linaro is planning the transition from eglibc to
>>>> glibc. They are asking what gaps remain in glibc that are
>>>> important to eglibc users. We realize that embedded is the
>>>> most likely where any gaps exist. Linaro toolchain builds
>>>> eglibc but they turn on all the options so they do not have a
>>>> lot of experience on scaling down.
>>>> 
>>>> Has oe-core already done or planned the transition to glibc?
>>> 
>>> It has not done it and the transition is not planned as yet.
>>> 
>>>> Have we identified any gaps?
>>> 
>>> The biggest issue is the lack of config options to cut down the
>>> size of eglibc.
>>> 
>>>> Has any one tried yp-tiny with glibc?
>>> 
>>> No, it won't work due to the issue above.
>> 
>> An open work item here is to complete research into the
>> limitations of uclibc to determine if the granular
>> componentization of eglibc is really needed, or if uclibc might
>> be a more appropriate option for poky-tiny.
> 
> I would say yes thats a good option to consider for tiny systems.
> 
>> 
>> Alternatively, given the complexity of working with the eglibc
>> config options and integrating it into a product, another option
>> would be to only make the division at individual libraries and
>> use uclibc when truly tiny is required.
>> 
>> Ultimately, I think this alternative is where we will land.
>> Especially if the resources can't be scratched together to do the
>> port ourselves.
>> 
>> My 0.02, for whatever it's worth.
>> 
>> -- Darren
>> 
>>> 
>>>> Linaro toolchain group is asking if there are any gaps that
>>>> need to be closed. I don't know enough to guide them.
>>> 
>>> The discussion was taken upstream:
>>> 
>>> http://www.eglibc.org/archives/patches/msg01276.html
>>> 
>>> but they've said no unless someone steps up to do the work.
>>> We're kind of in stalemate at the moment as I understand it.
>>> Khem or Mark may know more about the current status but I don't
>>> think much as changed since those emails.
>>> 
> 
> The changes w.r.t kconfigs is on our plate yes and I have plans but
> less of time towards it lately but I would make sure that it does
> not get dropped once eglibc is merged into glibc. Some pieces of
> this feature is outside of eglibc at present.
> 
>>> Cheers,
>>> 
>>> Richard
>>> 
>>> 
>>> 
>>> 
>> 
> 
> _______________________________________________ yocto-ab mailing
> list yocto-ab at yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto-ab

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKyDBAACgkQuwUzVZGdMxRucQCbBKZLXIrfigOjcOpXsYCvLwpR
k9AAoI55VWV/QSP2dGkqit5xC4qWN690
=jkzF
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x59545C11.asc
Type: application/pgp-keys
Size: 8598 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto-ab/attachments/20131218/4a55b7f0/attachment.key>