Re: Subdirs

[Roland McGrath <roland@frob.com>]

> Basically what I want to do is exclude a lot of the wide-character and
> internationalisation support.  From looking at the size of the generated
> binaries this contributes quite a lot of code and in many of my
> applications it's unnecessary.

I see.  You are concerned with code that is directly linked in, right, not
just the size of the shared library?  So which functions you are in fact
using refer to lots of code that you do not want?

> So what I want to do is exclude subdirs like gconv altogether, and also
> exclude a couple of other subdirs like stdio-common so that I can then
> substitute my own, more minimalist version.

Doing that sort of thing in a particular port sounds like a reason to use
exactly what you did.

> You could make a case for saying that glibc just isn't intended for this
> and I should be using something like newlib instead, but I'd prefer to be
> able to use the existing glibc code base (which is already ported to the
> main environments I'm interested in) rather than having to maintain a
> port of a separate library as well.

As the originator of glibc, I'll make the case that it was most certainly
always intended to be portable and apply to many different contexts.  I
would certainly like to see it made more flexible and usable in more
disparate ways.

> One thing I'd quite like to be able to do is build a more specialised
> version of, say, the i586-linux configuration for low memory
> environments.  I haven't fully thought about how this would work from a
> configuration point of view.

That becomes a hairy issue of the ABI dependency encodings.  Can you be
more specific about what you have in mind (i.e. what code you'd want to
leave out)?  Perhaps we can move some things into separate libraries, and
use linker magic to avoid users having to use -lfoobar for them.