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

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.

> 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 comparision Uriel proposed is quite fair in my eyes. Check
> out the memory consumption of a fully blown Plan 9 server with a
> X-less Linux server (the Plan 9 system with ftp, http, etc.
> services enabled and maybe exporting huge amounts of data using
> 9p servers).
>
> 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...

> (There's another good argument for static linking - try to run a
> dynamically linked ELF-binary from 2001 under todays Linux
> distributions, I bet you won't be very successful - but I can
> still run a statically linked a.out binary from 1991 on my
> bleeding edge Ubuntu box).
This is a different story. And I surely had most problems of
that kind on Linux (not Solaris nor AIX) up to now, because
there backwards compatibility is not considered as important
as with commercial software.

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).
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.

Regards,
Stefan

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer