Support for smaller glibc

Support for smaller glibc

[Ralf Baechle]

For the information of the embedded community.

  Ralf

----- Forwarded message from "H . J . Lu" <hjl@valinux.com> -----

Date: Fri, 1 Dec 2000 09:12:35 -0800
From: "H . J . Lu" <hjl@valinux.com>
To: Ralf Baechle <ralf@uni-koblenz.de>
Cc: sglibc@external-lists.valinux.com
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 sglibc@external-lists.valinux.com.


-- 
H.J. Lu (hjl@valinux.com)

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

  Ralf

Re: Support for smaller glibc

[Martin Michlmayr]

* Ralf Baechle <ralf@oss.sgi.com> [20001202 05:03]:
> For the information of the embedded community.
> 
>> BTW, please discuss it on sglibc@external-lists.valinux.com.

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

-- 
Martin Michlmayr
tbm@cyrius.com

Re: Support for smaller glibc

[Alan Cox]

> > 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.

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

Re: Support for smaller glibc

[Alan Cox]

> > 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.

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

Re: Support for smaller glibc

[Eric Jorgensen]

> 
> > > 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.
> 
> Ulrich is right. Start from a library that is intended to be modular and
> 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

Re: Support for smaller glibc

[Eric Jorgensen]

> 
> > > 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.
> 
> Ulrich is right. Start from a library that is intended to be modular and
> 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

Re: Support for smaller glibc

[Alan Cox]

> 	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

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

> 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.

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

> 	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. 

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

Re: Support for smaller glibc

[Alan Cox]

> 	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

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

> 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.

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

> 	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. 

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