Goal: Increased Modularity?

[Richi Plana]

On Wed, 2007-09-05 at 15:06 -0500, Les Mikesell wrote:
> Bill Nottingham wrote:
> > Les Mikesell (lesmikesell at gmail.com) said: 
> >>> dlopen will cause you to break at runtime instead of buildtime if
> >>> ABI changes - that's not good.
> >> You should expect things to break when you change an interface - pretty 
> >> much by definition.  If it hurts, don't do it.
> > 
> > I was discussing a case where instead of linking against libvorbis, you
> > dlopen() it - that's the sort of thing which is really much better to
> > catch at buildtime. If you're dlopening the plugin that is itself linked
> > against libvorbis (or whatever), that's better.
> 
> Won't anything using a shared library break if you replace that library 
> with one that does not follow the same interface definition whether it's 
> dlopen()ed or not?  That's kind of the whole concept of interfaces - 
> they aren't supposed to change.  If you write a new one, call it 
> something else.

That's what I meant when I said that catching interface changes like
that should be escalated to a higher layer: the version. It won't get
caught during loading of the executable (primarily because it's not
linked against it), but it's like any software you develop. You can put
error-checks at the lowest level function call and be assured of
catching everything, or putting them at a higher level making sure that
all entrances are checked. Coneptually, you could make changes to the
library that doesn't change the ABI but changes the semantics of the
function calls totally breaking the software that uses it but isn't
caught during linking (far-fetched though it may be).

The primary benefit to doing it this way (and a main concern of
distro-makers) is, of course, that packages don't need to hard-Require
optional modules (assuming they're optional to begin with). Other issues
aren't as interesting to distribution-makers and one could spend weeks
discussing the merits of doing it one way or another. Personally I've
written software that does both and I'm not convinced one is always
better over the other from a software developer's standpoint. Such isn't
the case for distro-makers.
--

Richi Plana