Re: Library reduction on Alpha (was: Re: Alpha: aboot rescue disk)
"Christopher C. Chimelis" <chris@debian.org> writes:
> On 8 Aug 2001, Goswin Brederlow wrote:
>
> > A short add on to mklibs.sh.
> >
> > As I see it it looks for symbols that are in two files, i.e. ash and
> > libm, and includes all matches. It thinks that all symbols that match
> > names will be needed in the library.
> >
> > Unfortunatly that will keep any and all symbols with all duplicates in
> > the library, so instead of using libc's math funktions it keeps libcs
> > _and_ libms.
>
> Ah, ok. So, if I understand this correctly, you want to only keep the
> symbols in libc/libm that are needed by the binaries on the boot floppies,
> correct? If so, I may have a scheme to do this, but I would have to see
Yes and now. mklibs.sh keeps all symbols needed, mklibs.py keeps only
one instance of each symbol needed.
We want that set of instances of symbols that results in a minimum of
space. Thats a NP complete problem, in general. So up to now we made a
few assumptions:
- the problem size is small. :)
- all binaries are roughly linked against the same set of libs
- duplicate symbols can savely be ignored, just pick one
(thats an extension of the previous one)
- versioned symbols will be ignored, or rather the version tag
> the scripts first (I'll check them out of CVS probably tomorrow) to make
> sure they don't already try that :-)
>
> > mklibs.py on the other hand includes each symbol only once. Theres a
> > small hack to prefer libc symbols (althout not realy needed since libm
> > seems to be after libc) but otherwise its a first come first use basis.
>
> Ok...this script probably does what I'm thinking about then. Is this one
> working well enough or do you want to shrink it even more?
If we can, sure. But the only thing that I see left si to remove
versioned symbols and leave only the right version or the minimal set
of version required. But does that realy help? Its probably just some
stubs that get removed by that.
Another idea would be to use a smaller (but slower) libc and to
optimize for size.
Currently the root.bin fits, so unless someone adds more the jobs
done, but that just a lazy programmers attitude. :)
MfG
Goswin
Reply to: