State of libcs in OE-Core glibc/uclibc/musl

State of libcs in OE-Core glibc/uclibc/musl

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

Hi All,

I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as of now, we have

glibc + cross localedef + kconfig patches which are left overs from eglibc days
uclibc - which is more of less unmaintained

Its a significant effort to keep forward porting the kconfig changes since it touches everywhere in glibc, (I do it in my local glibc tree)
almost every week there is a commit in upstream glibc which breaks the kconfig patches, I know there are distribution profiles
like poky-tiny which uses glibc in this capacity, and may be then their are other custom one’s made on top, I would like us to not carry major
patches which almost makes our component a fork due to obvious maintenance cost. I think there is viable alternatives to tiny libcs in musl now.

I would like to make a proposal for 2.1 release where

1. Drop kconfig support in glibc and we become inline with upstream
2. Move musl support to OE-Core from meta-musl
3. Drop uclibc or leave it in current broken state, I would like to pull it out into a layer in meta-openembedded and we can leave the core plumbing as it is in OE-Core
4. Poky-tiny switches to use musl

may other disto’s have moved to using musl as system C library e.g. alpine linux, openwrt, and I am also deploying it in  real products
its pretty mature and well maintained with very healthy community around it. Right now meta-musl is capable of building and running
core-image-sato/core-image-weston for all supported Qemu arches in OE-Core, the amount of software it can build is no less than uclibc
support in OE-Core.

if collectively we think, this is a good move then I can work on all of above items in early phases of 2.1 so we can settle any
outstanding issues, due to the shuffle especially in poky-tiny

Thoughts ?

-Khem

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Phil Blundell]

On Thu, 2015-10-29 at 08:42 -0700, Khem Raj wrote:

> I would like to make a proposal for 2.1 release where
> 
> 1. Drop kconfig support in glibc and we become inline with upstream
> 2. Move musl support to OE-Core from meta-musl
> 3. Drop uclibc or leave it in current broken state, I would like to
> pull it out into a layer in meta-openembedded and we can leave the
> core plumbing as it is in OE-Core
> 4. Poky-tiny switches to use musl

I have no opinion on point 4, but the first three things sound like an
excellent plan to me.

p.

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Dan McGregor]

On 29 October 2015 at 10:45, Phil Blundell <pb@pbcl.net> wrote:
> On Thu, 2015-10-29 at 08:42 -0700, Khem Raj wrote:
>
>> I would like to make a proposal for 2.1 release where
>>
>> 1. Drop kconfig support in glibc and we become inline with upstream
>> 2. Move musl support to OE-Core from meta-musl
>> 3. Drop uclibc or leave it in current broken state, I would like to
>> pull it out into a layer in meta-openembedded and we can leave the
>> core plumbing as it is in OE-Core
>> 4. Poky-tiny switches to use musl
>
> I have no opinion on point 4, but the first three things sound like an
> excellent plan to me.
>
> p.
>

I agree. How much of a burden is it to keep systemd running with musl?

> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Khem Raj]

On Thu, Oct 29, 2015 at 10:28 AM, Dan McGregor
<danismostlikely@gmail.com> wrote:
> On 29 October 2015 at 10:45, Phil Blundell <pb@pbcl.net> wrote:
>> On Thu, 2015-10-29 at 08:42 -0700, Khem Raj wrote:
>>
>>> I would like to make a proposal for 2.1 release where
>>>
>>> 1. Drop kconfig support in glibc and we become inline with upstream
>>> 2. Move musl support to OE-Core from meta-musl
>>> 3. Drop uclibc or leave it in current broken state, I would like to
>>> pull it out into a layer in meta-openembedded and we can leave the
>>> core plumbing as it is in OE-Core
>>> 4. Poky-tiny switches to use musl
>>
>> I have no opinion on point 4, but the first three things sound like an
>> excellent plan to me.
>>
>> p.
>>
>
> I agree. How much of a burden is it to keep systemd running with musl?

systemd is not for musl. fundamental goals of the projects are
different, so I dont even want to say it will be supported
although in meta-musl I have some patches which gets it to some
functional state. But systemd project wants to use
every feature that comes into glibc, and musl doesnt want to implement
anything extra on top of posix. So if we want
systemd with musl then its on own times either of community will help
with this. the situation is same with uclibc btw.

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Mark Hatle]

On 10/29/15 10:42 AM, Khem Raj wrote:
> Hi All,
> 
> I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as of now, we have
> 
> glibc + cross localedef + kconfig patches which are left overs from eglibc days

I do find the above useful -- include the kconfig part.

> uclibc - which is more of less unmaintained

I've never used uclibc with the Yocto Project framework.  I think musl is a lot
more compelling moving forward.

> Its a significant effort to keep forward porting the kconfig changes since it touches everywhere in glibc, (I do it in my local glibc tree)
> almost every week there is a commit in upstream glibc which breaks the kconfig patches, I know there are distribution profiles
> like poky-tiny which uses glibc in this capacity, and may be then their are other custom one’s made on top, I would like us to not carry major
> patches which almost makes our component a fork due to obvious maintenance cost. I think there is viable alternatives to tiny libcs in musl now.
> 
> I would like to make a proposal for 2.1 release where
> 
> 1. Drop kconfig support in glibc and we become inline with upstream

I really would like to keep kconfig support still.  It's definitely useful, but
it's of course not the main workflow.

> 2. Move musl support to OE-Core from meta-musl

I wouldn't object to his.

> 3. Drop uclibc or leave it in current broken state, I would like to pull it out into a layer in meta-openembedded and we can leave the core plumbing as it is in OE-Core

I definitely wouldn't object to this.  I do think keeping the uclibc hooks and
such in oe-core for the time being does make sense.  It would be interesting to
know how often it is still being used... (and I do think musl is a better
replacement for this use-case.)

> 4. Poky-tiny switches to use musl

I think there are two usages here.. one is a small 'glibc' interface where the
API is glibc compatible, but restricted..

And a "don't care about the libc, as long as it works and is small" use case
which was traditionally uclibc, but now can be fulfilled by musl.

I do still think a 'tiny' glibc is useful -- however with musl being a lot more
capable of working then uclibc was, the usefulness may be diminishing.

> may other disto’s have moved to using musl as system C library e.g. alpine linux, openwrt, and I am also deploying it in  real products
> its pretty mature and well maintained with very healthy community around it. Right now meta-musl is capable of building and running
> core-image-sato/core-image-weston for all supported Qemu arches in OE-Core, the amount of software it can build is no less than uclibc
> support in OE-Core.

This certainly makes it worthwhile to consider putting into oe-core proper.
Again, I have no objections to introducing musl.

--Mark

> if collectively we think, this is a good move then I can work on all of above items in early phases of 2.1 so we can settle any
> outstanding issues, due to the shuffle especially in poky-tiny
> 
> Thoughts ?
> 
> -Khem
> 
> 
> 

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Khem Raj]

On Thu, Oct 29, 2015 at 1:07 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 10/29/15 10:42 AM, Khem Raj wrote:
>> Hi All,
>>
>> I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as of now, we have
>>
>> glibc + cross localedef + kconfig patches which are left overs from eglibc days
>
> I do find the above useful -- include the kconfig part.
>
>> uclibc - which is more of less unmaintained
>
> I've never used uclibc with the Yocto Project framework.  I think musl is a lot
> more compelling moving forward.
>
>> Its a significant effort to keep forward porting the kconfig changes since it touches everywhere in glibc, (I do it in my local glibc tree)
>> almost every week there is a commit in upstream glibc which breaks the kconfig patches, I know there are distribution profiles
>> like poky-tiny which uses glibc in this capacity, and may be then their are other custom one’s made on top, I would like us to not carry major
>> patches which almost makes our component a fork due to obvious maintenance cost. I think there is viable alternatives to tiny libcs in musl now.
>>
>> I would like to make a proposal for 2.1 release where
>>
>> 1. Drop kconfig support in glibc and we become inline with upstream
>
> I really would like to keep kconfig support still.  It's definitely useful, but
> it's of course not the main workflow.

its a lot of work and upstream is not so keen on supporting it either,
so even if we spend time to clean it up
and send upstream it might need dedicated maintenance which is going
to be quite frequent breakages
since no one will test all kconfig combos. At this point this is the
biggest drag to take glibc forward I spend lot of time on keeping
these
patches moving forward. so we want
to avoid needless effort if there is so little userbase for it. Cross
localedef and others we still will keep.

>
>> 2. Move musl support to OE-Core from meta-musl
>
> I wouldn't object to his.
>
>> 3. Drop uclibc or leave it in current broken state, I would like to pull it out into a layer in meta-openembedded and we can leave the core plumbing as it is in OE-Core
>
> I definitely wouldn't object to this.  I do think keeping the uclibc hooks and
> such in oe-core for the time being does make sense.  It would be interesting to
> know how often it is still being used... (and I do think musl is a better
> replacement for this use-case.)
>
>> 4. Poky-tiny switches to use musl
>
> I think there are two usages here.. one is a small 'glibc' interface where the
> API is glibc compatible, but restricted..
>
> And a "don't care about the libc, as long as it works and is small" use case
> which was traditionally uclibc, but now can be fulfilled by musl.
>
> I do still think a 'tiny' glibc is useful -- however with musl being a lot more
> capable of working then uclibc was, the usefulness may be diminishing.
>
>> may other disto’s have moved to using musl as system C library e.g. alpine linux, openwrt, and I am also deploying it in  real products
>> its pretty mature and well maintained with very healthy community around it. Right now meta-musl is capable of building and running
>> core-image-sato/core-image-weston for all supported Qemu arches in OE-Core, the amount of software it can build is no less than uclibc
>> support in OE-Core.
>
> This certainly makes it worthwhile to consider putting into oe-core proper.
> Again, I have no objections to introducing musl.
>
> --Mark
>
>> if collectively we think, this is a good move then I can work on all of above items in early phases of 2.1 so we can settle any
>> outstanding issues, due to the shuffle especially in poky-tiny
>>
>> Thoughts ?
>>
>> -Khem
>>
>>
>>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Mark Hatle]

On 10/29/15 3:14 PM, Khem Raj wrote:
> On Thu, Oct 29, 2015 at 1:07 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 10/29/15 10:42 AM, Khem Raj wrote:
>>> Hi All,
>>>
>>> I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as of now, we have
>>>
>>> glibc + cross localedef + kconfig patches which are left overs from eglibc days
>>
>> I do find the above useful -- include the kconfig part.
>>
>>> uclibc - which is more of less unmaintained
>>
>> I've never used uclibc with the Yocto Project framework.  I think musl is a lot
>> more compelling moving forward.
>>
>>> Its a significant effort to keep forward porting the kconfig changes since it touches everywhere in glibc, (I do it in my local glibc tree)
>>> almost every week there is a commit in upstream glibc which breaks the kconfig patches, I know there are distribution profiles
>>> like poky-tiny which uses glibc in this capacity, and may be then their are other custom one’s made on top, I would like us to not carry major
>>> patches which almost makes our component a fork due to obvious maintenance cost. I think there is viable alternatives to tiny libcs in musl now.
>>>
>>> I would like to make a proposal for 2.1 release where
>>>
>>> 1. Drop kconfig support in glibc and we become inline with upstream
>>
>> I really would like to keep kconfig support still.  It's definitely useful, but
>> it's of course not the main workflow.
> 
> its a lot of work and upstream is not so keen on supporting it either,
> so even if we spend time to clean it up
> and send upstream it might need dedicated maintenance which is going
> to be quite frequent breakages
> since no one will test all kconfig combos. At this point this is the
> biggest drag to take glibc forward I spend lot of time on keeping
> these
> patches moving forward. so we want
> to avoid needless effort if there is so little userbase for it. Cross
> localedef and others we still will keep.

I definitely understand this.... I wonder if the right answer is to create a
project for this either under the Yocto Project umbrella or just as a separate
project.. everything remains 'glibc' except for the kconfig chunk.

That -might- be able to relieve the burden from your shoulders.. but it wouldn't
be an overnight process.  (And if nobody actually cares, it might prove that
point and make it easier to justify removing.)

>>
>>> 2. Move musl support to OE-Core from meta-musl
>>
>> I wouldn't object to his.
>>
>>> 3. Drop uclibc or leave it in current broken state, I would like to pull it out into a layer in meta-openembedded and we can leave the core plumbing as it is in OE-Core
>>
>> I definitely wouldn't object to this.  I do think keeping the uclibc hooks and
>> such in oe-core for the time being does make sense.  It would be interesting to
>> know how often it is still being used... (and I do think musl is a better
>> replacement for this use-case.)
>>
>>> 4. Poky-tiny switches to use musl
>>
>> I think there are two usages here.. one is a small 'glibc' interface where the
>> API is glibc compatible, but restricted..
>>
>> And a "don't care about the libc, as long as it works and is small" use case
>> which was traditionally uclibc, but now can be fulfilled by musl.
>>
>> I do still think a 'tiny' glibc is useful -- however with musl being a lot more
>> capable of working then uclibc was, the usefulness may be diminishing.
>>
>>> may other disto’s have moved to using musl as system C library e.g. alpine linux, openwrt, and I am also deploying it in  real products
>>> its pretty mature and well maintained with very healthy community around it. Right now meta-musl is capable of building and running
>>> core-image-sato/core-image-weston for all supported Qemu arches in OE-Core, the amount of software it can build is no less than uclibc
>>> support in OE-Core.
>>
>> This certainly makes it worthwhile to consider putting into oe-core proper.
>> Again, I have no objections to introducing musl.
>>
>> --Mark
>>
>>> if collectively we think, this is a good move then I can work on all of above items in early phases of 2.1 so we can settle any
>>> outstanding issues, due to the shuffle especially in poky-tiny
>>>
>>> Thoughts ?
>>>
>>> -Khem
>>>
>>>
>>>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 5041 bytes --]


> On Oct 29, 2015, at 1:26 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> 
> On 10/29/15 3:14 PM, Khem Raj wrote:
>> On Thu, Oct 29, 2015 at 1:07 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> On 10/29/15 10:42 AM, Khem Raj wrote:
>>>> Hi All,
>>>> 
>>>> I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as of now, we have
>>>> 
>>>> glibc + cross localedef + kconfig patches which are left overs from eglibc days
>>> 
>>> I do find the above useful -- include the kconfig part.
>>> 
>>>> uclibc - which is more of less unmaintained
>>> 
>>> I've never used uclibc with the Yocto Project framework.  I think musl is a lot
>>> more compelling moving forward.
>>> 
>>>> Its a significant effort to keep forward porting the kconfig changes since it touches everywhere in glibc, (I do it in my local glibc tree)
>>>> almost every week there is a commit in upstream glibc which breaks the kconfig patches, I know there are distribution profiles
>>>> like poky-tiny which uses glibc in this capacity, and may be then their are other custom one’s made on top, I would like us to not carry major
>>>> patches which almost makes our component a fork due to obvious maintenance cost. I think there is viable alternatives to tiny libcs in musl now.
>>>> 
>>>> I would like to make a proposal for 2.1 release where
>>>> 
>>>> 1. Drop kconfig support in glibc and we become inline with upstream
>>> 
>>> I really would like to keep kconfig support still.  It's definitely useful, but
>>> it's of course not the main workflow.
>> 
>> its a lot of work and upstream is not so keen on supporting it either,
>> so even if we spend time to clean it up
>> and send upstream it might need dedicated maintenance which is going
>> to be quite frequent breakages
>> since no one will test all kconfig combos. At this point this is the
>> biggest drag to take glibc forward I spend lot of time on keeping
>> these
>> patches moving forward. so we want
>> to avoid needless effort if there is so little userbase for it. Cross
>> localedef and others we still will keep.
> 
> I definitely understand this.... I wonder if the right answer is to create a
> project for this either under the Yocto Project umbrella or just as a separate
> project.. everything remains 'glibc' except for the kconfig chunk.
> 

that sounds a good idea. May be the patch can be picked from 2.0 release and maintained there separately
and applied but not via OE-Core that way it will get maintained as well as used by interested parties.

> That -might- be able to relieve the burden from your shoulders.. but it wouldn't
> be an overnight process.  (And if nobody actually cares, it might prove that
> point and make it easier to justify removing.)

I think this is more likely the practical case

> 
>>> 
>>>> 2. Move musl support to OE-Core from meta-musl
>>> 
>>> I wouldn't object to his.
>>> 
>>>> 3. Drop uclibc or leave it in current broken state, I would like to pull it out into a layer in meta-openembedded and we can leave the core plumbing as it is in OE-Core
>>> 
>>> I definitely wouldn't object to this.  I do think keeping the uclibc hooks and
>>> such in oe-core for the time being does make sense.  It would be interesting to
>>> know how often it is still being used... (and I do think musl is a better
>>> replacement for this use-case.)
>>> 
>>>> 4. Poky-tiny switches to use musl
>>> 
>>> I think there are two usages here.. one is a small 'glibc' interface where the
>>> API is glibc compatible, but restricted..
>>> 
>>> And a "don't care about the libc, as long as it works and is small" use case
>>> which was traditionally uclibc, but now can be fulfilled by musl.
>>> 
>>> I do still think a 'tiny' glibc is useful -- however with musl being a lot more
>>> capable of working then uclibc was, the usefulness may be diminishing.
>>> 
>>>> may other disto’s have moved to using musl as system C library e.g. alpine linux, openwrt, and I am also deploying it in  real products
>>>> its pretty mature and well maintained with very healthy community around it. Right now meta-musl is capable of building and running
>>>> core-image-sato/core-image-weston for all supported Qemu arches in OE-Core, the amount of software it can build is no less than uclibc
>>>> support in OE-Core.
>>> 
>>> This certainly makes it worthwhile to consider putting into oe-core proper.
>>> Again, I have no objections to introducing musl.
>>> 
>>> --Mark
>>> 
>>>> if collectively we think, this is a good move then I can work on all of above items in early phases of 2.1 so we can settle any
>>>> outstanding issues, due to the shuffle especially in poky-tiny
>>>> 
>>>> Thoughts ?
>>>> 
>>>> -Khem
>>>> 
>>>> 
>>>> 
>>> 
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: State of libcs in OE-Core glibc/uclibc/musl

[Roman Khimov]

В письме от 29 октября 2015 08:42:31 пользователь Khem Raj написал:
> 1. Drop kconfig support in glibc and we become inline with upstream

No opinion on this.

> 2. Move musl support to OE-Core from meta-musl

I would certainly support this kind of for musl.

> 3. Drop uclibc or leave it in current broken state, I would like to pull it
> out into a layer in meta-openembedded and we can leave the core plumbing as
> it is in OE-Core

But I don't think that moving uClibc out of OE Core is OK with the next 
release. We do use it and there are probably some users too, I think it's 
better to have a longer transition period for this kind of change, like make 
the next release support three libcs and only move uClibc to meta-oe in a 
subsequent release. This would give everyone some time to evaluate 
alternatives rather than forcing to make choices right at the OE Core update 
when usually there are lots of other things that need to be fixed.

> 4. Poky-tiny switches to use musl

No opinion on this.

Re: State of libcs in OE-Core glibc/uclibc/musl

[akuster808]

On 10/29/2015 08:42 AM, Khem Raj wrote:
> Hi All,
> 
> I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as of now, we have
> 
> glibc + cross localedef + kconfig patches which are left overs from eglibc days
> uclibc - which is more of less unmaintained
> 
> Its a significant effort to keep forward porting the kconfig changes since it touches everywhere in glibc, (I do it in my local glibc tree)
> almost every week there is a commit in upstream glibc which breaks the kconfig patches, I know there are distribution profiles
> like poky-tiny which uses glibc in this capacity, and may be then their are other custom one’s made on top, I would like us to not carry major
> patches which almost makes our component a fork due to obvious maintenance cost. I think there is viable alternatives to tiny libcs in musl now.
> 
> I would like to make a proposal for 2.1 release where
> 
> 1. Drop kconfig support in glibc and we become inline with upstream

Inline with upstream make a lot of sence and will help make maintenance
simpler going forward.

> 2. Move musl support to OE-Core from meta-musl

I see no issue with this.

> 3. Drop uclibc or leave it in current broken state, I would like to pull it out into a layer in meta-openembedded and we can leave the core plumbing as it is in OE-Core
If its not being maintained, then drop by 2.1.

> 4. Poky-tiny switches to use musl

If Poky-tiny is meant to showcase the smallest of the small , then that
make sense.

- armin

> 
> may other disto’s have moved to using musl as system C library e.g. alpine linux, openwrt, and I am also deploying it in  real products
> its pretty mature and well maintained with very healthy community around it. Right now meta-musl is capable of building and running
> core-image-sato/core-image-weston for all supported Qemu arches in OE-Core, the amount of software it can build is no less than uclibc
> support in OE-Core.
> 
> if collectively we think, this is a good move then I can work on all of above items in early phases of 2.1 so we can settle any
> outstanding issues, due to the shuffle especially in poky-tiny
> 
> Thoughts ?
> 
> -Khem
> 
> 
> 

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Andre McCurdy]

On Fri, Oct 30, 2015 at 9:21 AM, akuster808 <akuster808@gmail.com> wrote:
>
>
> On 10/29/2015 08:42 AM, Khem Raj wrote:
>> Hi All,
>>
>> I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as of now, we have
>>
>> glibc + cross localedef + kconfig patches which are left overs from eglibc days
>> uclibc - which is more of less unmaintained
>>
>> Its a significant effort to keep forward porting the kconfig changes since it touches everywhere in glibc, (I do it in my local glibc tree)
>> almost every week there is a commit in upstream glibc which breaks the kconfig patches, I know there are distribution profiles
>> like poky-tiny which uses glibc in this capacity, and may be then their are other custom one’s made on top, I would like us to not carry major
>> patches which almost makes our component a fork due to obvious maintenance cost. I think there is viable alternatives to tiny libcs in musl now.
>>
>> I would like to make a proposal for 2.1 release where
>>
>> 1. Drop kconfig support in glibc and we become inline with upstream
>
> Inline with upstream make a lot of sence and will help make maintenance
> simpler going forward.
>
>> 2. Move musl support to OE-Core from meta-musl
>
> I see no issue with this.
>
>> 3. Drop uclibc or leave it in current broken state, I would like to pull it out into a layer in meta-openembedded and we can leave the core plumbing as it is in OE-Core
> If its not being maintained, then drop by 2.1.

Maintenance of uclibc seems to have moved to the uclibc-ng project:

  http://www.uclibc-ng.org/

Developers are active and they make regular releases. Buildroot
switched to uclibc-ng as the default uclibc a few months ago and it
seems to be working OK for them:

  http://git.buildroot.net/buildroot/commit/?id=68d4a3b5a6a6d03d67418e0b637628ecf9cbf192


>> 4. Poky-tiny switches to use musl
>
> If Poky-tiny is meant to showcase the smallest of the small , then that
> make sense.
>
> - armin
>
>>
>> may other disto’s have moved to using musl as system C library e.g. alpine linux, openwrt, and I am also deploying it in  real products
>> its pretty mature and well maintained with very healthy community around it. Right now meta-musl is capable of building and running
>> core-image-sato/core-image-weston for all supported Qemu arches in OE-Core, the amount of software it can build is no less than uclibc
>> support in OE-Core.
>>
>> if collectively we think, this is a good move then I can work on all of above items in early phases of 2.1 so we can settle any
>> outstanding issues, due to the shuffle especially in poky-tiny
>>
>> Thoughts ?
>>
>> -Khem
>>
>>
>>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of libcs in OE-Core glibc/uclibc/musl

[Khem Raj]

On Fri, Oct 30, 2015 at 11:31 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Fri, Oct 30, 2015 at 9:21 AM, akuster808 <akuster808@gmail.com> wrote:
>>
>>
>> On 10/29/2015 08:42 AM, Khem Raj wrote:
>>> Hi All,
>>>
>>> I would like to get everyone’s opinion on the libcs we maintain in OE-Core, as of now, we have
>>>
>>> glibc + cross localedef + kconfig patches which are left overs from eglibc days
>>> uclibc - which is more of less unmaintained
>>>
>>> Its a significant effort to keep forward porting the kconfig changes since it touches everywhere in glibc, (I do it in my local glibc tree)
>>> almost every week there is a commit in upstream glibc which breaks the kconfig patches, I know there are distribution profiles
>>> like poky-tiny which uses glibc in this capacity, and may be then their are other custom one’s made on top, I would like us to not carry major
>>> patches which almost makes our component a fork due to obvious maintenance cost. I think there is viable alternatives to tiny libcs in musl now.
>>>
>>> I would like to make a proposal for 2.1 release where
>>>
>>> 1. Drop kconfig support in glibc and we become inline with upstream
>>
>> Inline with upstream make a lot of sence and will help make maintenance
>> simpler going forward.
>>
>>> 2. Move musl support to OE-Core from meta-musl
>>
>> I see no issue with this.
>>
>>> 3. Drop uclibc or leave it in current broken state, I would like to pull it out into a layer in meta-openembedded and we can leave the core plumbing as it is in OE-Core
>> If its not being maintained, then drop by 2.1.
>
> Maintenance of uclibc seems to have moved to the uclibc-ng project:
>
>   http://www.uclibc-ng.org/
>
> Developers are active and they make regular releases. Buildroot
> switched to uclibc-ng as the default uclibc a few months ago and it
> seems to be working OK for them:
>
>   http://git.buildroot.net/buildroot/commit/?id=68d4a3b5a6a6d03d67418e0b637628ecf9cbf192

Thats something needs to waited and watched.

>
>
>>> 4. Poky-tiny switches to use musl
>>
>> If Poky-tiny is meant to showcase the smallest of the small , then that
>> make sense.
>>
>> - armin
>>
>>>
>>> may other disto’s have moved to using musl as system C library e.g. alpine linux, openwrt, and I am also deploying it in  real products
>>> its pretty mature and well maintained with very healthy community around it. Right now meta-musl is capable of building and running
>>> core-image-sato/core-image-weston for all supported Qemu arches in OE-Core, the amount of software it can build is no less than uclibc
>>> support in OE-Core.
>>>
>>> if collectively we think, this is a good move then I can work on all of above items in early phases of 2.1 so we can settle any
>>> outstanding issues, due to the shuffle especially in poky-tiny
>>>
>>> Thoughts ?
>>>
>>> -Khem
>>>
>>>
>>>
>> --
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: State of libcs in OE-Core glibc/uclibc/musl

[Khem Raj]

On Fri, Oct 30, 2015 at 4:10 AM, Roman Khimov <roman@khimov.ru> wrote:
> В письме от 29 октября 2015 08:42:31 пользователь Khem Raj написал:
>> 1. Drop kconfig support in glibc and we become inline with upstream
>
> No opinion on this.
>
>> 2. Move musl support to OE-Core from meta-musl
>
> I would certainly support this kind of for musl.
>
>> 3. Drop uclibc or leave it in current broken state, I would like to pull it
>> out into a layer in meta-openembedded and we can leave the core plumbing as
>> it is in OE-Core
>
> But I don't think that moving uClibc out of OE Core is OK with the next
> release. We do use it and there are probably some users too, I think it's
> better to have a longer transition period for this kind of change, like make
> the next release support three libcs and only move uClibc to meta-oe in a
> subsequent release. This would give everyone some time to evaluate
> alternatives rather than forcing to make choices right at the OE Core update
> when usually there are lots of other things that need to be fixed.

may be not a bad idea however, this still will be available as an
independent layer on meta-openembedded
but we could still keep it for a release

>
>> 4. Poky-tiny switches to use musl
>
> No opinion on this.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: State of libcs in OE-Core glibc/uclibc/musl

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]

On Fri, Oct 30, 2015 at 01:55:42PM -0700, Khem Raj wrote:
> On Fri, Oct 30, 2015 at 4:10 AM, Roman Khimov <roman@khimov.ru> wrote:
> > В письме от 29 октября 2015 08:42:31 пользователь Khem Raj написал:
> >> 1. Drop kconfig support in glibc and we become inline with upstream
> >
> > No opinion on this.

I agree, it can be outside oe-core and enabled + maintained by those who
care about it, it doesn't need to burden you Khem when you're doing all
glibc upgrades in oe-core.

> >> 2. Move musl support to OE-Core from meta-musl
> >
> > I would certainly support this kind of for musl.

I agree, it looks like more reasonable replacement for uclibc.

> >> 3. Drop uclibc or leave it in current broken state, I would like to pull it
> >> out into a layer in meta-openembedded and we can leave the core plumbing as
> >> it is in OE-Core
> >
> > But I don't think that moving uClibc out of OE Core is OK with the next
> > release. We do use it and there are probably some users too, I think it's
> > better to have a longer transition period for this kind of change, like make
> > the next release support three libcs and only move uClibc to meta-oe in a
> > subsequent release. This would give everyone some time to evaluate
> > alternatives rather than forcing to make choices right at the OE Core update
> > when usually there are lots of other things that need to be fixed.
> 
> may be not a bad idea however, this still will be available as an
> independent layer on meta-openembedded
> but we could still keep it for a release

I agree again, few people are using it (based on recent survey from
Cliff), so having it in separate layer looks good to me.

> >
> >> 4. Poky-tiny switches to use musl
> >
> > No opinion on this.

I won't ever use poky-tiny, but switching it from glibc+kconfig to musl
would probably make it easier to do some build testing on Yocto AB, so
in the end it should improve test-coverage than current uclibc in
oe-core has.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]