Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[static] linking



[miah: Mar 20 07:47]
> Sounds like you've had this problem pop up before.  Maybe the distro you're running is doing things wrong?  Maybe you're building your partitions incorrectly?
> 

I was just way too flip - sorry bout that.. not enough coffee.

Sure I've had this problem, but it was long before RHS existed.. but
my point is the RHS is just a standard while code is tangible and that
goes to the crux of the 'what is static linking good for' question.

static linking eliminates some environmental variables. In a very
conservative environment like troubleshooting/debugging/recovery you
want as few variables as possible because if everything were working
in spec you wouldn't be in this unfortunate position to start with. So
yeah, I think having a statically linked shell, ln, mount, cp, cat and
maybe even a small vi is a good practice. e2fsck?

it used to be very common for people to really screw up when upgrading
libc. Typically you have something like:

lrwxrwxrwx    1 root     root           13 Nov 14 11:00 /lib/libc.so.6-> libc-2.2.5.so
-rwxr-xr-x    2 root     root      1260480 Oct 10 11:16 /lib/libc-2.2.5.so

and you go and add a libc-2.2.6.so.. it was not uncommon for people to
do "rm /lib/libc.so-6; ln -s /lib/libc-2.2.6.so /lib/libc.so-6".. but
of course the ln would fail if it was dynamically linked. Yes, there
was a way to do this right and avoid the pitfal, but fixing the
screwup was a hell of a lot easier with some basic tools statically
linked.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org