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



Chuck Young writes:
| The only good reason I can think of to link/compile -static is to not =
| have to depend on and trust the shared libraries, which could be altered =
| by a rootkit, etc.  This provides you with a so-called "trusted" binary, =
| albeit bloated :)
|
| But hey, if they fit on a CD, who cares!  It's kind of an oddball =
| situation though.  I can't think of another good reason to do it if the =
| machine is reasonably secure/hardened.
|
| Are there other good reasons?

Sure.  I've been bitten by compiling code on release X of a
system, copying it to a release Y machine, and finding that
it can't find the libraries that it expects.  With a static
binary,  this  doesn't  happen.   Of  course, the binary is
bigger.

An interesting case of this:  When people get into  talking
about  the  supposed  disagreements and rivalry between the
linux and *BSD systems, I  like  to  mention  that  I  have
accounts  on linux, FreeBSD and OpenBSD systems, and I copy
binaries between them with no problems.  There may be a lot
of public discussion going on, not all of it friendly.  But
in the background, they are keeping their OSs  sufficiently
in sync that they can run each others' binaries.

But this is really only reliable with static binaries.   If
you  copy a binary that calls shared libraries, the chances
of it working are smaller.





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