This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Support for smaller glibc

On Wed, Nov 29, 2000 at 10:24:04AM -0600, Mark Brown wrote:
> > I work as a programmer trying to fit Linux+Mozilla+X into 16 meg of disk
> > space (flash card) for a semi-embedded system; being able to disable
> > chunks of glibc at build-time would be a wonderful thing (from my
> > perspective). So yes, there is interest :-)
> This is to acknowledge that there is a *lot* of interest, I know I get
> queried on this from my co-workers.
> But having the same .so name contains so many possibilities for error
> that I am against that aspect of this discussion. Also there is the 

Having the same soname doesn't mean problems automatically. Please
check what sonames glibc 2.0/2.1/2.2 use. My point is it is doable. 

> issue of different environments needing different things removed; I do not
> think we can have a "small build" option that makes everyone happy. The
> developer will have to be the judge of what is cut out.
> What we *should* do is ensure that things *can* be cut out, at least by
> maintaining a design that does not "tie everything to everything else".

That is the part of my suggestion. The other part is we should do it in
such a way that we can have the same soname.

I should make one correction. The normal glibc should be 100% binary
compatible with the small glibc. But the small glibc is not 100% binary
compatible with the normal one. If you compile things under the
normal glibc, which only use the functions supported in the small glibc,
they should work fine against the small glibc. You can see that the
small glibc is glibc 2.0 with all bug fixes and symbol versioning.

H.J. Lu (

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]