On Thursday 22 November 2007 18:09, Richard Hoyle wrote:
> a) Is removing the --gc-sections lines from scripts/trylink now
> the recommended way to do this (if one must)?
Yes
> b) Why do some utils finish with a (indirect) call to
> fflush(stdout), and others do not? Wouldn't it be better to
> call fflush in all utils or call fflush in none?
It allows them to return exit code 1 ("error") if there was
a problem writing to standard output.
It should be done only in those utilities which primary
result is stdout output (e.g. cat, sort, sed).
For example, modprobe does not need to do that.
> c) Might it not be a good idea to update the warning in applets.c
> re the location of --gc-sections?
Done.
> d) The warning in applets.c contains:
>
> "Note that glibc is unsuitable for static linking anyway"
>
> Most of busybox seems to work just fine being statically linked
> against glibc. What other issues are you aware of that impact
> on static builds against glibc?
glibc' method of loading libnss libraries assumes dynamic linking.
There was a bug at some point when statically linked ping didn't work.
It is now possibly fixed, I don't track that issue.
It seems that glibc people just don't regard static linking
as "normal" usage for glibc, and maybe even don't support it outright.
As a result of this, they don't expend any effort in making
static link to be at least reasonably small.
Currently, even "int main() { return 0; }" program,
when linked statically against glibc, will pull in
malloc code (it uses malloc somewhere in init code),
which will pull in printf, which will pull in
internationalization and gettext support,
which will pull in almost everything else.
You will end up with ~400k binary, which is ~60%
of full-blown busybox.
Yes, it works, it's just makes size-saving efforts
in busybox moot.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
