[tor-dev] [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure

[Ivan Markin]

Yawning Angel:
> Having to rebuild the browser when the libc needs to be updated seems
> terrible as well.

Why is it terrible?
Using static linking drastically reduces overall *complexity*
(~1/security). If you do use libc code in your stuff then it's a part of
this stuff.  If there is a bug in libc - just rebuild your broken
software. It either works or not. Doing dynamic linking is leaving it in
superposition state.

I consider having the browser that builds for >30m is way more terrible.

From
https://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/
:

> I prefer static linking:

> Executing statically linked executables is much faster, because there
> are no expensive shared object lookups during exec().
> 
> Statically linked executables are portable, long lasting and fail
> safe to ABI changes -- they will run on the same architecture even in
> 10 years time. Never expect errors like
> /lib/ssa/libstdc++.so.6:version 'GLIBCXX_3.4.4' not found again.
> 
> Statically linked executables use less disk space. Most executables
> use only a small subset of the functions provided by a static library
> -- so there is absolutely no reason to link complete static libraries
> into a static executable (e.g. spoken for a hello_world.c you only
> need to link vprintf statically into the executable, not the whole
> static libc!). The contrary is true for dynamic libraries -- you
> always use the whole library, regardless what functions you are
> using.
> 
> Statically linked executables consume less memory because their
> binary size is smaller and they only map the functions they depend on
> into memory (contrary to dynamic libs).
> 
> The reason why dynamic linking has been invented was not to decrease
> the general executable sizes or to save memory consumption, or to
> speed up the exec() -- but to allow changing code during runtime --
> and that's the real purpose of dynamic linking, we shouldn't forget
> that.

--
Ivan Markin