[BusyBox] here's a working multicall for e2fsprogs-1.18 _with_ uClibc support for i386
Manuel Novoa III
mnovoa3 at bellsouth.net
Fri Jan 19 15:33:05 UTC 2001
Vladimir,
> > I've attached the information I _think_ you're asking for...
> > the sizes of all the .o and .a files that were built.
>
> Yes. It is interesting to me.
> I see, that you have not taken advantage most likely of an option -Os.
Actually, everything was compiled with -Os -fomit-frame-pointer.
The shared bins generated for uClibc are slightly larger than those
generated linking with glibc; I guess that's what you're noticing.
One of the items on my personal list is to find out why... and fix it. ;-)
Please remember that shared uClibc is brand new and I know I haven't
had the time to really look at it yet. What time I have had I've used to
update the gcc-uClibc wrapper for shared uClibc and to fix some of
the things that broke in the unified syscall support.
> Moreover, if you have time particularly for development of this module
> for busybox,
My primary focus has become uClibc, and I don't really intend to pursue
working on "e2fsbox". I threw it together yesterday mainly as an excersise.
I wanted to show that a shared uClibc could be used for other applications
that someone might want on a rescue disc or a mini distribution. Also, as the
support libs for the e2fs utilities are rather large, I wanted to show that you
could bundles these functions in one executable.
I guess you could say that I posted this:
1) as an advertisement for shared uClibc -- not much sense having a shared lib
for only one application. ;-)
2) as a jumping-off point for anyone who was interested in developing it. As I
mentioned in my original post, anyone who wants to is welcome to run with
this.
> will take advantage of an opportunity to reduce quantity
> of files, having brought in some functions in required files as static
> is too will give appreciable effect in the sum. I also think, that set
> of utilities from misc are not necessary in busybox as
> consequence - is possible to simplify a code of some universal
> functions.
If I were thinking about doing this, I would have to ask myself the question:
Are the size-reduction benefits of heavily modifying the original code
base worth the cost of tracking changes in the base distribution?
My initial thought was probably not, but the e2fs utilities are reasonably
stable so tracking bug-fixes and such shouldn't be that much of a problem.
Also, with the (admittedly slow) approach of ext3 you could probably ignore
e2fsck. I can certainly see an arguement to do mke2fs and badblocks at least.
Manuel
More information about the busybox
mailing list