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

[Jonathan Gapen]

On Sun, 5 Jan 2003, Richard Frith-Macdonald wrote:
> 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?

     For the most part, the AmigaOS system.  It works like this:
     The programmer (or built-in compiler support) would use the
OpenLibrary() call to open a shared library, specifying a minimum version
number.  That function returned a memory address, called the library base,
that the programmer assigned to a global variable.  The library has an
array of pointers to its functions immediately after the library base in
memory--  a jump table.  The compiler would simply generate code to load
an address at a certain offset from the library base to call a function.
     This scheme does have its disadvantages, to be sure, and maybe it's
like the Windows DLL scheme, but the point is it does have some
advantages, too.

> 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
> [...]
> 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.

     That would work on systems that have major and minor numbers.  Of the
systems I have installed, NetBSD has them.  FreeBSD 4.7 and Solaris 2.6 do
not.  Also, I think it's a strange convention to break backwards
compatibility with each major revision number--  especially since it's
often *not* broken with Unix libraries but just assumed so because that's
the convention.  (E.g. I have symlinked libintl.so.3 to libintl.so.4 for a
few binary-only programs that need it.)

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

     That would be the case if we're talking about, say, libc!  But there
are lots of cases where a program might want to support an optional
feature if the library is available.  A car still runs if it doesn't have
a leather interior and an in-dash GPS.  For instance, some programs will
use X11 or run as a command-line utility.  Or look at GNUstep's optional
libraries from the package manager's point of view.  Either the package
maintainer imposes a certain set of supported libraries, or provides:
     gnustep-base.rpm
     gnustep-base+iconv.rpm
     gnustep-base+xml2.rpm
     gnustep-base+iconv+xml2.rpm
     ...ad nauseum if there are more options...

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

     Oh yes, I agree, and I don't even build static libraries when I can
avoid it.  Still, the speed is poor from a user-interface perspective, and
Unix systems are used more and more on the desktop these days.

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

     I guess this is where our opinions vary.  I don't see why a higher
major revision must break backwards compatibility.
     As far as package managers, I haven't used a lot of them.  However,
in FreeBSD, you can't upgrade a package if others depend on it.  Sure, you
can force a deinstall and install the new one, but that leaves the package
database inconsistent.  You can install a third-party package which does
the upgrade and fixes up the package database for you, though.  When I
last used RPM, it was the same way.

> Or you can 'install' the new package, leaving the old one in place, and
> other packages won't need upgrading.

     You can't leave the old package in place-- files from the new one
will overwrite the old package's files and the package database is again
inconsistent.  Then if you delete the old package, the new one often
ceases to work as its files are gone.  If you remove the old package, but
keep the old shared objects in place, then the package database is
incomplete.  I suppose you could add the old objects into the database as
part of the new package, but you don't know what external files the shared
library needed, and that'll break if the user re-installs that package.
     Welcome to package manager hell.  :-)

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

     Well, can we just agree that there's room for improvment?