[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