Re: Support for smaller glibc

[Jay Carlson <nop at nop dot com>]

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'll make this a little more concrete.

Here's 2.0.6, built for default mipsel-linux with -msoft-float:

/tmp appeal$ mipsel-linux-strip libc-2.0.7.so 
/tmp appeal$ ls -l libc-2.0.7.so 
-rwxr-xr-x    1 nop      nop        992812 Dec  1 22:09 libc-2.0.7.so
/tmp appeal$ mipsel-linux-size libc-2.0.7.so 
text	data	bss	dec	hex	filename
778570 	32848  	40848  	852266 	d012a  	libc-2.0.7.so

Here's 2.2, built for default mipsel-linux with -msoft-float:

nop@decoy:/tmp$ mipsel-linux-strip libc.so.6
nop@decoy:/tmp$ ls -l libc.so.6
-rwxr-xr-x    1 nop      nop       1493980 Dec  1 21:11 libc.so.6
nop@decoy:/tmp$ mipsel-linux-size libc.so.6
text	data	bss	dec	hex	filename
1261509	26176  	17336  	1305021	13e9bd 	libc.so.6

By way of comparison, 2.4.0test-something with appropriate hardware
support for the VTech Helio.  Not compressed, no ramdisk compiled in.

nop@decoy:/tmp$ mipsel-linux-size ~/l5/linux/vmlinux
text	data	bss	dec	hex	filename
859876 	71528  	230896 	1162300	11bc3c 	/home/nop/l5/linux/vmlinux

Now, let's look at the hardware it's running on.  The VTech Helio has
8M RAM, 2M flash.  Kernel is decompressed into RAM at startup; root fs
is cramfs, at ~3:1 compression. The Agenda VR3d has 8M RAM, 16M flash;
kernel from rom, main filesystem cramfs.

MIPS sure looks bloaty, so I'm working on it.  Building -mips2 (with
my binutils patch) shaves around 10-15% off those .text numbers.
Barring major gcc work, the remaining systemic density fixes look to
come from large, incompatible ABI changes.

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

Ideally, I would like to be able to support full glibc, and that's why
I'm looking at those ABI changes.  But we've already got an minor ABI
incompatibility in the form of soft-float, so I'm not at all worried
about breaking hapless clueless users.  There are people using these
incompatible mips softfloat glibc images, sure, but all of them can
rebuild all their binaries from source at will at this point in time.

I think Ulrich is worrying more about what could happen on the x86
side.  Somebody announces Red Lamer Linux, a new 2-floppy modular
distribution with a tweaked libc.so that randomly breaks old and new
binaries because of missing or unversioned symbols.  But Red Lamer
Linux is K00L and OPTIMIZED!!! so it's not important what messes they
make for the rest of the mainstream desktop/server Linux community.

I will be honest: I don't understand what's going on inside glibc.
But I do understand that when I go at it with a buzzsaw, it's not the
glibc maintainers' fault when I cut myself.

Whether the glibc core team likes it or not, people like me are going
to perpetrate changes to the glibc source and build procedure to cut
size for our non-desktop requirements.  Because many different people
have some of the same requirements, we would like to pool our efforts.
Ideally, we would like to do so via the glibc distribution and CVS and
etc; if not, we'll issue patches against it and use another forum to
collaborate.

Working on cutting size in the main glibc project does create more
work for people like Ulrich, especially in the areas like test and
release management like he mentioned.  Some of that is intentional:
we'd like the people who really understand glibc top to bottom to
spend some small amount of brainpower on not gratuitously breaking
feature-cut glibc.  But I think we can all agree that the amount of
time spent worrying about this in mainline glibc should be minimized,
and the people who want to do the slicing should do the majority of
the work.  Size-reduced glibc should be an example of software reuse,
not project redirection.

By the way, if you want to keep non-mainline glibc from happening, you
should hurry up and break static libc---most of my work is based on
it. :-)

Jay