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

[Khem Raj]

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.

>
>> 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