Re: Discuss-gnustep Digest, Vol 2, Issue 12

[Richard Frith-Macdonald]

On Sunday, January 5, 2003, at 07:21  am, Jonathan Gapen wrote:

>      That might also help a little bit with the dependency problem, 
> but as
> I see it, the Unix shared library implementation is terrible.

I'm not sure if I'm just curious, or if I'm writing in defence of unix 
... but what
real or theoretical alternative are you using as a basis for this 
judgment?

> It's
> fragile, has poor backwards compatibility, is inflexible, is slow, and
> every platform has a subtly different implementation!  If your 
> executable
> links to libxml2.so.4, it needs THAT file, and libxml2.so.5 won't work.
> You don't know whether libxml2.so.5 is compatible, anyway.

As I understand it, the point of the major version number in a shared 
library is precisely to indicate whether versions are compatible or not 
... ie if the numbers differ (as above) then you *do* know that they 
are *not* compatible (in theory ... the actual practice depends on the 
developers producing the libraries of course).

So if you link with libxml2.so.4 then your app will work with 
libxml2.so.4.0.1 and libxml2.so.4.2.3 and libxml2.so.4.5.0 etc etc.

> Loading your
> executable fails if libxml2.so.4 isn't available--

Yes ... I view that as analagous to saying that your car doesn't run if 
you don't put fuel in it.  Package/dependency management software is Of 
course, you do have the option of using static rather than shared 
libraries if you view this as a big problem.

> you as the programmer
> have no choice about whether to run without it.

Rather like a car driver having no choice about whether to have an 
engine in the car or not ... the libraries linked with an application 
are an integral part of that application and I don't see what 'choice' 
you are saying the programmer should have.  Presumably the programmer 
made a choice to link with a library (rather than writing all the code 
themselves).  The programmer also has the choice of providing 
dynamically loaded code (simplified as bundles in GNUstep) which could 
be linked with different libraries if they want to.  So you *can* run 
without particular libraries by producing alternative implementations 
of the functionality your app needs.

> And all those name
> lookups when linking many shared libraries make process startup slow.

Yep ... I think that's an inherent drawback of shared libraries ... 
which is why static linking is sometimes used ... but for most 
applications people think the trade-off between binary size and startup 
time favours shared libraries.

>      A shared library system that addressed these deficiencies would
> eliminate "RPM dependency hell" for the most part.  A new package might
> require a newer version of libxml2, but you could install that newer
> version without the need to re-install every other package that 
> depends on
> libxml2.  Wouldn't that be nice?

That's how it works now in most package managers isn't it?

You can 'upgrade' in which case the new package replaces the old one, 
and if the dynamic libraries in the new package have a different major 
version number than executables linked to the old one will need to be 
upgraded.
Or you can 'install' the new package, leaving the old one in place, and 
other packages won't need upgrading.

Of course, the package manager may not keep records properly and may 
force you to re-install packages unnecessarily ... but that's a fault 
of the package manager rather than the shared libraries.

My feeling is that unix shared libraries are good for backward 
compatibility,  and flexible.  I don't really argue with slow, perhaps 
implementations could be faster of course, but startup time is 
fundamentally always going to be slower than static linked software.

The only alternative I know of is the windows dll ... and shared 
libraries are superior in all respects to that option ... what 
alternative model are you thinking of? or are you just saying that 
you'd prefer static linkage in spite of the binary size penalty?
I realise that the size may not be a big deal for some people, but I 
only have a 64Kbs link, and the download size is *very* significant to 
me.