Re: Static linking?

[bruce@pixar.com (Bruce Perens)]

> I've begun to wonder a bit about the above subject after reading an 
> article in a newsgroup somewhere.
>
> It mentioned something about problems with a dynamic linked e2fsck(and 
> friends) that has been installed on some distributions.  Anyhow, the 
> bottom line was that it should be static linked so problems with libc(?) 
> wouldn't keep you from fixing your fs.
> 
> But as far as I can see it doesn't really matter, as if something 
> thrashes libc, the system will never get as far as to run fsck due to 
> various (init, bash, update) other commands being dynamic linked with libc.

This is my asessment of the situation.

> I know it is wise to keep a disaster recovery floppy or three, but if 
> your system hasn't had any serious mishaps for 8 months or more, such 
> disks tend to be recycled for other use or just disappear.
> Just wondering, wouldn't it be wise to at least let the most important 
> commands be static so it is possible to boot into single-user mode if you 
> (or anything else) does something stupid to libc?  

Note that static-linked tools use more RAM when they are running.
Thus, we don't want that to happen to basic stuff like "sh" and "init"
that are always running.

Here's a solution: Let's put an option in the system installation
to make a "recovery partition". This installs the "rescue floppy"
in a 2MB partition on your hard disk along with the rest of the system.
Then, you press the partition number at the MBR prompt when your system 
is booting, and you are booted from a read-only independent root filesystem
while you repair your main root. This has the advantage that it is more
stable than static-linked executables on a broken filesystem, and it actually
takes less space than static-linking the boot-to-fsck tool chain.

	Thanks

	Bruce

	
--
Pixar Animation Studios: Reality is not our business.
Pixar's "Toy Story", at greater than $184,200,000 in domestic box office
receipts, is the #1 movie released in 1995!