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

[Khem Raj]

> On Oct 29, 2015, at 1:26 PM, Mark Hatle <mark.hatle at 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 at 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 at lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20151029/53615f48/attachment-0002.sig>