[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    [OE-core] [oe] State of libcs in OE-Core glibc/uclibc/musl
From:       raj.khem () gmail ! com (Khem Raj)
Date:       2015-10-30 0:26:05
Message-ID: 96CD693B-7FFA-47F9-8D9F-FC7E749B8C1C () gmail ! com
[Download RAW message or body]


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



[prev in list] [next in list] [prev in thread] [next in thread]