[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 20:54:33
Message-ID: CAMKF1sqcE8r_wRwKnfhg7T=Q2knr8yBLPpxn+6T=N5j31ndgPA () mail ! gmail ! com
[Download RAW message or body]

On Fri, Oct 30, 2015 at 11:31 AM, Andre McCurdy <armccurdy at gmail.com> wrote:
> On Fri, Oct 30, 2015 at 9:21 AM, akuster808 <akuster808 at 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 at lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel


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