This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Support for smaller glibc
- To: libc-alpha at sourceware dot cygnus dot com
- Subject: Re: Support for smaller glibc
- From: Jay Carlson <nop at nop dot com>
- Date: Fri, 01 Dec 2000 22:57:57 -0500
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