tlug: Re: static binaries (was: Re: tomsrtbt & glibc)

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Rex" == Rex Walters <rex@example.com> writes:

>>>>> Scott Stone writes:  (on 04 Nov 98)

    >> This seems to be a subjective opinion, one that doesn't seem to
    >> be followed by most Linux distributions, at least.  Wouldn't
    >> this lead to some excessive bloat?

    Rex> I'd have sworn one of the versions of the Filesystem
    Rex> Hierarchy Standard (http://www.pathname.com/fhs/) talked
    Rex> about statically linked binaries, but the 2.0 version only
    Rex> mentions statically linked ln and sync in /sbin (and then
    Rex> only for linux specifically).

    Rex> Without going through all the old FSSTND stuff, does anyone
    Rex> know if/when/why the recommendations changed?

AFAIK it did not change.  ln and sync _must_ be statically linked or
you couldn't update libc on a running system (or something like that).

    Rex> *Everything* in /sbin and /bin seems way overkill, but I'd
    Rex> certainly want at least a statically linked fsck laying
    Rex> around somewhere.  Rescue disks are handy, but sheesh.

If it's "way overkill," it probably doesn't belong in /bin or /sbin.
(You're most welcome, Mr. Sekiya.)

I bet you'd be surprised at how little bloat you actually get; many of
the library functions those utilities pull in will be unique to one,
and many of the rest will only show up in a couple.  Most library
functions won't be used at all.  I wouldn't be surprised (but don't
have the time to try the experiment) if my current 1326kB in /sbin and
1511kB in /bin ended up under 5MB with static links.  No biggee, IMO,
YMMV.

Tokoro de, it is still, and will remain for the forseeable future,
XEmacs policy to distribute only statically linked binaries on
ftp.xemacs.org.  For good reason: last year the RPM volunteer put up
some dynamically linked RPMs for 20.3, which accounted for close to
100% of the "XEmacs doesn't work at all" bug reports (for the binary
kits) that weren't pure pilot error.  (Red Hat updated some lib*.so
and *blooey*.)  They also contain all symbols, although they are
compiled without extra debug information and memory checks so they're
usably fast.

Now _that_ _would_ be bloat if done in a Linux distribution.

    Rex> *Somewhere* years ago (urban legends? admin
    Rex> abuse? kibology?) I read an amazing (hysterical) description
    Rex> of an admin saving a system that was gradually losing
    Rex> filesystems piecemeal using only a bourne shell and a
    Rex> statically linked c compiler he managed to copy from
    Rex> someplace before it went south.

I _want_ a copy!  Don't forget to put it in the FAQ, too.  :-)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences        Telfax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
----------------------------------------------------------------
Next Nomikai: 20 November, 19:30   Tengu TokyoEkiMae 03-3275-3691
Next Technical Meeting: 12 December, 12:30 HSBC Securities Office
----------------------------------------------------------------
more info: http://tlug.linux.or.jp Sponsors: PHT, HSBC Securities