[BusyBox] e2fsbox from e2fsprogs-1.19.tar.gz. Anyone interested.

Manuel Novoa III mjn3 at busybox.net
Fri May 18 08:57:01 UTC 2001


On Fri, May 18, 2001 at 02:32:03PM +0000, Tom Oehser wrote:
> > Can you explain how it manages to reduce the size so much? 
> 
> How exactly is 163640 so good?  It looks roughly comparable to:
> 
> -rwxr-xr-x   1 nobody   32766        4717 May 12 23:37 /rb/2/usr/bin/dumpe2fs
> -rwxr-xr-x   2 nobody   32766       71229 May 12 23:37 /rb/2/usr/bin/e2fsck
> -rwxr-xr-x   1 nobody   32766       16289 May 12 23:37 /rb/2/usr/bin/mke2fs
> -rwxr-xr-x   1 nobody   32766        4076 May 12 23:37 libcom_err.so.2
> -rwxr-xr-x   1 nobody   32766       11576 May 12 23:37 libe2p.so.2
> -rwxr-xr-x   1 nobody   32766       68980 May 12 23:37 libext2fs.so.2
> -rwxr-xr-x   1 nobody   32766       13792 May 12 23:37 libss.so.2
> -rwxr-xr-x   1 nobody   32766        8132 May 12 23:37 libuuid.so.1
> 
> Which is my 1.19 ext2fs stuff.  I am hoping to get around to running
> mklibs.sh on the libraries, etc., and get it smaller, but I would have
> thought if it was combined it would have been smaller than 165...

Out of curiousity, why are you bothering with the e2fs shared libs if you're
building a multicall e2fs program?  Why not just staticly link against the
e2fs libs and dynamiclly link against libc?

Presumably, nothing else will use the e2fs libs.  Any unneeded objects in
the libs will be omitted and you save the overhead needed by the shared libs.

Manuel







More information about the busybox mailing list