Re: [wmii] patches for shared object libixp and Sun compiler

On Mon, Jan 15, 2007 at 04:51:44PM +0100, Stefan Tibus wrote:
> On Mon, 15 Jan 2007 14:41:00 +0100 Anselm R. Garbe:
> > Actually that is an argument which is repeated quite often, but
> > it hasn't been the real intention of dynamic linking. Dynamic
> > linking has been originally invented to replace code being
> > executed during runtime.
> Well... I was thinking of what dynamic linking is useful for.
> And I can't see a reason to use it in order to prevent code
> from being executed.
>
> > There was some need back in the 70s
> > to achieve this in the financial sector, where specific
> > processes on mainframes could not be stopped for various
> > reasons, but laws and calculation methods changed during the
> > runtime of such processes, hence the idea was to replace such
> > methods by updating libraries.
> ...so you mean replacing a lib with an improved version
> without having to stop and change the program? That's
> acutally another very good reason.

Well that was the intention when dynamic linking has been
invented.

> > The argument you describe is more a side-effect of software
> > getting bloaty more and more. Considered you refer to a fully
> > blown desktop environment like KDE or Gnome, I believe that a
> > desktop system would consume 2-5 times more memory without
> > dynamic linking. But in general the difference in memory
> > consumption seems negligible once if you compare
> > statically-linked userlands to dynamically-linked userlands.
> With KDE and Gnome this is getting more obvious, but the
> effect is there with any lib that is used by more than
> just a single program. Dynamic libraries are somewhat like
> functions. Imagine you would have to code without functions -
> the code would be faster, but much longer.
> Dynamic linking is somewhat like calls to the BIOS or OS, why
> should all those functions reside several times in memory,
> identical copies, but one for each running program? An extreme
> version of static linking would be to have the complete OS
> within a single, huge monolitic application... would that be
> good? Maybe, in some special cases, but not in general.

The point Uriel tries to make in my eyes (which is similiar to
my point) - without dynamic linking developers are forced to
consider simplicity and memory consumption, that leads to a
saner environment (which is simplier and uses less memory). With
dynamic linking they simply don't consider this, because there's
memory code segment sharing due the benefit of dynamic linking,
hence they can bloat the software much more and the more insane
software gets... Think of static linking as a complexity killer.

I'd also differentiate between linking executable code and
organizing source code. It is out of question that there should
be libraries and that atomic functions like read/write which
belong to an API should not be implemented several times, they
should be implemented in libc a nowhere else.

There are good reasons however, that each binary is statically
linked with the object code of such functions instead of stubs
which or dlopen'ed later. Two reasons which haven't been mentioned
yet are simplicity of function calls and security.

With simplicity of function calls I mean, that a statically
linked executable has the advantage, that library functions are
inlined and can be called directly and drastically faster. With
dynamic linking the linking has to be done at least on fork() -
if it's done in a trivial way, but more favorizable would be on
each function call (assumed there is some cache which tracks if
a reload has to be performed after a lib has been
updated/replaced). This means execution gets much more complex
(additional software layers) and slower (due to complexity).

Static linked binaries provide a better security in general,
because a compromised library allows an attacker to compromise a
system due exploiting any executable which is dynamically linked
with that library. It is much harder to achieve this with statically
linked binaries. But this security concern might be a
pathological example in the Unix world.

> > Another comparision is: Just check out the binary size of
> > completely statically linked binaries against fefe's dietlibc or
> > uClibc and compare that to the sizes of the same source code
> > being dynamically linked against GNU libc (or the commercial
> > counterparts from Sun). I believe you will be surprised.
> Well...that's comparing apples with oranges. If you want
> to check the benefit of dynamic vs static linking, you sure
> have to compare both using the same lib! Otherwise you're
> just comparing the size and efficiency of those libs. One
> could use uClibc dynamically linked as well...

This was not intended to make a comparision of static vs dynamic
linking, both have its right to exist. It was more intended as
an example how dynamic linkage leads to bloaty software like GNU
libc.

But there's also another very heavyweight technical argument
when discussing about static vs. dynamic linkage.

Consider a simple hello world program dynamically linked against
libc - such program only uses printf. To execute that program
and assumed no other program has been executed so far (ignore
init and Co. in this example), the whole(!) libc needs to be loaded
into the memory (dunno how much memory GNU libc consumes).

If you consider the same example with a statically linked
hello program, it only needs to bind the relevant printf object code
into the binary. If that is executed, no bloaty lib has to be
loaded as well.

The point of this is, nearly no program makes use of all library
functions. I'd even argue, that no C program uses more than 5%
of all libc functions, hence, you need to execute A LOT of
dynamically programs to really benefit from dynamic linking.

> However, the libixp and wmii Makefiles allow for dynamic
> linking of libixp now and I was just trying to get it to
> work correctly, without any valuation whether that would
> be a good idea or not (in the case of wmii/libixp static
> linking seems better to me, at least for me it's the only
> app using libixp).

That's true and I can understand that. You never argued that
dynamic linking is better.

> But I just can't stand it if somebody then comes in and
> destructively judges everything using dynamic linking as
> crap. This is not helpful at all and just clogging my
> mailbox - that's why I was writing personal mails. But
> if Uriel has to drag this into public I can't help it.

You know the argumentation scheme of Uriel, so don't get pissed
off by him ;)

Regards,

-- 
 Anselm R. Garbe >< http://suckless.org/~arg/ >< GPG key: 0D73F361