Subject: Support for smaller glibc

From: Ralf Baechle <[email-masked]>
Date: Sat, 2 Dec 2000 05:03:06 +0100

For the information of the embedded community.

  Ralf

----- Forwarded message from "H . J . Lu" <[email-masked]> -----

Date: Fri, 1 Dec 2000 09:12:35 -0800
From: "H . J . Lu" <[email-masked]>
To: Ralf Baechle <[email-masked]>
Cc: [email-masked]
Subject: Re: Support for smaller glibc

On Fri, Dec 01, 2000 at 02:14:14PM +0100, Ralf Baechle wrote:
> On Tue, Nov 28, 2000 at 04:24:29PM -0800, H . J . Lu wrote:
> 
> > The current glibc 2.2 has many features. But some of them are not
> > needed in some cases. I am wondering if there is an interest to
> > make those features configurabled at the build time. The ones I am
> > thinging now are intl, iconv, iconvdata, locale, localedata, wcsmbs,
> > wctype and wide char IO. They will be enabled by default. But you
> > can disable them at the build time. It will make glibc much smaller.
> > Any comments?
> 
> The MIPS community is shifting more and more into the embedded area; one
> of the increasing pains is glibc's increasing size which makes various
> people continue to maintain glibc 2.0, the oldest and smallest libc for
> MIPS.  So your suggestion is very interesting indeed.
> 
> I just have acknowledge Uli's concerns in this thread; they need to be
> solved.  But forking a smaller libc of standard glibc is nothing but the
> St. Florian's principle ...
> 

Ulrich is refusing to do anything with it. Do you have any suggestions?
I will do my best to do it right. But I am afraid I cannot do it alone.

BTW, please discuss it on [email-masked].

-- 
H.J. Lu ([email-masked])

----- End forwarded message -----

  Ralf

---

From: Martin Michlmayr <[email-masked]>
Date: Sat, 2 Dec 2000 12:25:20 +0000

>> BTW, please discuss it on [email-masked].

See http://external-lists.valinux.com/lists/listinfo/sglibc/

-- 
Martin Michlmayr
[email-masked]

---

From: Alan Cox <[email-masked]>
Date: Sat, 2 Dec 2000 13:06:28 +0000 (GMT)

> I will do my best to do it right. But I am afraid I cannot do it alone.

Ulrich is right. Start from a library that is intended to be modular and
embedded. Folks are already looking at using newlib for this. 

Alan

---

From: Eric Jorgensen <[email-masked]>
Date: Sat, 2 Dec 2000 09:13:45 -0700 (MST)

> embedded. Folks are already looking at using newlib for this. 

	There are a few other methods. Lineo for instance has a utility
called Lipo which goes through all the binaries on a system and then
strips out all the library code that's unused, usually resulting in a
substantial reduction in the size of libc6. Lipo is a proprietary
app tho, currently only available supporting ia32 and ppc archetectures as
part of the Embedix SDK.

	There's also uClibc, and i've heard some talk of using bsd's libc,
which i understand is also smaller. These may require modification to the
sourcecode of your apps to work properly. 

 - Eric

---

From: Alan Cox <[email-masked]>
Date: Sat, 2 Dec 2000 16:31:53 +0000 (GMT)

> called Lipo which goes through all the binaries on a system and then

Try it on a real application and with glibc 2.2 at least its far from
large. glibc isnt designed to be modular.

> app tho, currently only available supporting ia32 and ppc archetectures as

Lipo is an afternoons work to do with libbfd so thats a path that is easy
to pursue. (

> sourcecode of your apps to work properly. 

BSD libc is smaller, uClibc is pretty ropey and not very modular. Both the
BSD libc and newlib are modular. Newlib for mips32 without mips16 support 
including FPU emulation with every option on is about 350K