Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>,
	<openembedded-devel@lists.openembedded.org>,
	Yocto Project <yocto@yoctoproject.org>
Subject: [RFC] eglibc / glibc and option-groups being deprecated?
Date: Tue, 18 Jun 2013 16:00:35 -0500	[thread overview]
Message-ID: <51C0CA73.7090606@windriver.com> (raw)

Recently on the eglibc mailing list there has been a discussion about removing 
the option groups.  See: http://www.eglibc.org/archives/patches/msg01268.html

For folks who don't know what option-groups are, it's a patch that went into 
eglibc a number of years ago that allows you to disable various components 
(effectively altering the API) in order to shrink the size of glibc.

It was created as an attempt to get into glibc the same type of configuration 
ability that uclibc has.

In OpenEmbedded Core, it is currently being used to enable the ability to shrink 
the LibC footprint to a smaller size.  The Yocto Project's Poky-tiny 
distribution uses it as part of the mechanism to create a smaller filesystem.

I encourage you to read the original thread, and if it affects you, please speak 
up.  The following is my attempt at summarizing the thread.

Currently the maintainer(s) of eglibc are working on syncing up glibc and eglibc 
to the point that there will no longer be a need for eglibc.  (See 
http://www.eglibc.org/archives/patches/msg01261.html)

EGlibc was originally developed to house various architecture ports and other 
embedded friendly features were not allowed into glibc.  The majority of the 
differences between eglibc and glibc have disappeared, with only a few major 
exceptions.  One of which is the option-groups support.  This item is taking a 
significant amount of resources to keep up to date, and it's unclear as to the 
number of users for this functionality.

The belief of the maintainers is that the days of truly small footprint systems, 
where even 1 MB of storage was a large number are coming to an end.  As such, 
the time and effort to maintain the option groups is likely not worth the effort.

I expect that between OpenEmbedded and the Yocto Project, a large percentage of 
the users would be represented in some way.  But beyond that, I don't have any 
idea as to how many people actually benefit from this technology.

During the discussion the results were that either assistance with maintaining 
the option-groups is needed, or the feature will be deprecated and eventually 
removed.  The last part of the thread it was suggested that in eglibc 2.19 it 
would be deprecated, and then removed in 2.20.

--Mark


                 reply	other threads:[~2013-06-18 21:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=51C0CA73.7090606@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=yocto@yoctoproject.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox