> On Oct 29, 2015, at 1:26 PM, Mark Hatle <mark.ha...@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.ha...@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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
