From: akuster808 <akuster808@gmail.com>
To: Khem Raj <raj.khem@gmail.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>,
Martin Jansa <Openembedded-devel@lists.openembedded.org>
Subject: Re: [OE-core] State of libcs in OE-Core glibc/uclibc/musl
Date: Fri, 30 Oct 2015 09:21:33 -0700 [thread overview]
Message-ID: <5633990D.3090308@gmail.com> (raw)
In-Reply-To: <9D79B6D4-2FE1-4C77-A359-C0F47DCC090D@gmail.com>
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.
> 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
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: akuster808 <akuster808@gmail.com>
To: Khem Raj <raj.khem@gmail.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>,
Martin Jansa <Openembedded-devel@lists.openembedded.org>
Subject: Re: State of libcs in OE-Core glibc/uclibc/musl
Date: Fri, 30 Oct 2015 09:21:33 -0700 [thread overview]
Message-ID: <5633990D.3090308@gmail.com> (raw)
In-Reply-To: <9D79B6D4-2FE1-4C77-A359-C0F47DCC090D@gmail.com>
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.
> 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
>
>
>
next prev parent reply other threads:[~2015-10-30 16:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 15:42 State of libcs in OE-Core glibc/uclibc/musl Khem Raj
2015-10-29 16:45 ` [oe] " Phil Blundell
2015-10-29 17:01 ` [OE-core] " Tim Orling
2015-10-29 20:09 ` Khem Raj
2015-10-29 20:20 ` Tim Orling
2015-10-29 17:28 ` Dan McGregor
2015-10-29 17:28 ` [oe] " Dan McGregor
2015-10-29 19:52 ` [OE-core] " Khem Raj
2015-10-29 19:52 ` [oe] " Khem Raj
2015-10-29 20:07 ` Mark Hatle
2015-10-29 20:07 ` [oe] " Mark Hatle
2015-10-29 20:14 ` [OE-core] " Khem Raj
2015-10-29 20:14 ` [oe] " Khem Raj
2015-10-29 20:26 ` [OE-core] " Mark Hatle
2015-10-29 20:26 ` [oe] " Mark Hatle
2015-10-30 0:26 ` [OE-core] " Khem Raj
2015-10-30 0:26 ` [oe] " Khem Raj
2015-10-30 11:10 ` [OE-core] " Roman Khimov
2015-10-30 11:10 ` Roman Khimov
2015-10-30 20:55 ` [OE-core] " Khem Raj
2015-10-30 20:55 ` Khem Raj
2015-10-30 21:03 ` [OE-core] " Martin Jansa
2015-10-30 21:03 ` Martin Jansa
2015-10-30 16:21 ` akuster808 [this message]
2015-10-30 16:21 ` akuster808
2015-10-30 18:31 ` [OE-core] " Andre McCurdy
2015-10-30 18:31 ` [oe] " Andre McCurdy
2015-10-30 20:54 ` [OE-core] " Khem Raj
2015-10-30 20:54 ` [oe] " Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5633990D.3090308@gmail.com \
--to=akuster808@gmail.com \
--cc=Openembedded-devel@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.