From: joel@wam.umd.edu (Joel M. Hoffman) Subject: Re: /bin files should not be linked with shared libs! Date: 11 Mar 1993 02:19:24 GMT
In article <C3pC8D.Gun@ra.nrl.navy.mil> eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:
>In article <C3oypC.27z@umassd.edu> benu@cis.umassd.edu (David Hassel) writes:
>> I know there has already been a discussion on this issue but /bin
>>file should not be linked with shared libs. A good example of this is how
>>would you boot if libc.so.xx got corrupted? I made the silly mistake of
>>removing the link to libc.so.4 and expected to re-ln it immediately.
>>ln, cp, cat, etc all were linked against the [missing] shared library.
>
> How would you boot if [init, getty, bash, login] were corrupted? What
>if you put something stupid in your rc, rc.local, or inittab which prevented
>you from getting in to your system? Basically you cannot get away from the
>fact that there are certain files which must be present and uncorrupt for the
>system to come up. The bootable rootdisk is designed to recover from these
>types of problems.
It is of course true that, in principle, there are dozens of easy way
to make Linux unbootable. But, from reading c.o.l. for many months,
it does appear that having a staticly linked ln would have saved MANY
problems. Is there anything really wrong with including a statically
linked ln standard? (Or, if you're concerned about general
performance with ln, how about a ln.static, that just sits around,
watiting for the operator to do something stupid.)
Come to think of it, statically linked umount.static, mount.static and
cp.static would be enough to fix almost any shared-lib related
problem. No?
-Joel
(joel@wam.umd.edu)