From: Mark Hatle <fray@mvista.com>
To: Marius Groeger <mag@sysgo.de>
Cc: Erik Christiansen <erik@dd.nec.com.au>,
Darin.Johnson@nokia.com, linuxppc-embedded@lists.linuxppc.org
Subject: Re: glibc vs. newlib
Date: Tue, 08 Apr 2003 11:27:44 -0500 [thread overview]
Message-ID: <3E92F880.8080500@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.52.0304081831450.3191@mag.devdep.sysgo.de>
Marius Groeger wrote:
> On Mon, 7 Apr 2003, Mark Hatle wrote:
>
>
>>looks promising. For a more traditional linux system, glibc is
>>truely the only way to do it. (With special tools you can
>>dramatically reduce the size of glibc, but not as far as most people
>>would like.)
>
>
> This kind of size reduction (aka. "optimisation") sounds sort of scary
> to me. Glibc is a big and complicated beast (look, for instance, at
> the rather loose ties by which the libnss-stuff is held together). You
> seem to have some experience here. Can you seriously recommend this
> for _production_ software?
Absolutly. The optimizations that are supported in both open source and by
companies like the one I work for (MontaVista Software) are pretty simple.
Specifically they re-link the shared library based on the requirements of the
rest of the files in the filesystem.
This linking occurs on the original *.o files that produced the original glibc.
Internal and external glibc dependencies are fully resolved and the resulting
binary is as-if you built glibc and just #ifdef-ed out a lot of code... (FYI
there are a few implicit glibc dependencies that have to be known by the tool
itself as they can't be gleamed from objdump.)
The key with this type of optimization though is that it is very specific to a
given filesystem. Don't expect to add large chunks of functionality to an
existing filesystem, without first having to re-link glibc for any pieces that
may be missing.
As far as the libnss stuff goes, in reality it's rarely an issue for the systems
that need this type of optimization. They don't have a true users/groups setup,
nor usually have internet connectivity (requiring DNS). (At least that has been
my experience.)
So short answer, running a glibc "optimizer" which re-links the original glibc
.o files is absolutly safe and supportable.. you just have to understand what it
means and how it works to decide if it is right for your application.
--Mark
(Just as a note, I speak for myself and not my company when I write to these
lists... unless I specifically claim to be speaking for MontaVista)
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-04-08 16:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-04 23:08 glibc vs. newlib Darin.Johnson
2003-04-04 23:19 ` Gary D. Thomas
2003-04-04 23:38 ` Wolfgang Denk
2003-04-05 1:30 ` Mark Hatle
2003-04-07 1:47 ` Erik Christiansen
2003-04-07 6:05 ` Mark Hatle
2003-04-08 16:36 ` Marius Groeger
2003-04-08 16:27 ` Mark Hatle [this message]
[not found] ` <3E92FABD.8050307@imc-berlin.de>
2003-04-08 17:03 ` Mark Hatle
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=3E92F880.8080500@mvista.com \
--to=fray@mvista.com \
--cc=Darin.Johnson@nokia.com \
--cc=erik@dd.nec.com.au \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=mag@sysgo.de \
/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;
as well as URLs for NNTP newsgroup(s).