> The "just-link-everything-together" approach has been taken several times.
> Look at busybox, for example. There is one for FreeBSD (the name escapes
> me) ...
It's used by the PicoBSD (single diskette FreeBSD
systems). There are a couple of different task-oriented
versions of the PicoBSD floppies; one for dial-in client,
one for dial-out client, and one for LAN router and/or
diskless client or print server use.
Home Page of PicoBSD 2.2.5
http://www.freebsd.org/~picobsd/picobsd225/
Their "busybox" like binaries are created/linked using
a utility called 'crunchgen'. I think the PicoBSD package
predates the Linux busybox.
> ... that purports to automate it. The first problem is symbol
> collision. What if both programs have a "counter-39" variable?
> The linker will crap out. So, you really have to have something
> process all the object files and rename or preface any duplicate
> symbols, or do it manually... Also, the gain I have always looked
> for is the reduction in overhead of the C runtime. The library
> issues aren't really an advantage. You still have a huge waste of
> space if you statically link to libc6, you still have to fix your
> include files, there isn't a big win there. I personally
> recommend you get the libc5-kit from my add-ons directory and
> figure out the issues for doing libc5-linking and just make it
> work with libc5. If you are ...
I agree that glibc2 (libc6) has a huge footprint.
Has anyone profiled it to see where all the bloat
is coming from?
I've also always been amazed that nobody's written
a linker with some sort of "dead library code" removal
(where only those members of a .a library archive that are
actually referenced in the code are linked into the
resulting binary).
It seems like the UNIX standard libraries are causing
more problems then they are solving. Many buffer
overflows and other exploitable bugs result from
reliance on stdio and stdlib functions that are pitfalls
for "mere mortal" programmers.
BTW: Tom, have you looked at asmutils?
Linux/i386 assembly programming page
http://lightning.voshod.com/asm/
... these are VERY tiny (implementing about 50
common UNIX/Linux shell utilities in assembly
by doing direct system calls --- and thus not
linked to any libraries). They have a web server
that's implemented in ~780 bytes. That's the
largest of the utilities in the package.
Might this save some space on Tom's Root/Boot?
> ... adding a significant number of things, and are unwilling to
> learn the tricks to make it work with libc5, then just make your
> own libc6 setup, and use libc6 versions of everything, and go all
> the way libc6. For what you are trying to do, linking a bunch of
> programs into one big kludge and fixing all the symbol conflicts
> is going to be mroe trouble than it is worth. Um, the BSD one is
> called "crunch", research it if you want. Or just use the busybox
> approaches (and fix symbol collisions manually...). I suspect you
> can get everything compiled to libc5 without enough trouble to
> make it worth the other approaches... and if you do, why not just
> _start_ with a libc6 bootdisk?
> -Tom
> On Sun, 5 Dec 1999, Joonas Timo Taavetti Kekoni wrote:
>> This process would be easier automate that backporting libraries
>> and hunting down missing includes.
--
Jim Dennis [EMAIL PROTECTED]
Linuxcare: Linux Corporate Support Team: http://www.linuxcare.com
