Writing Shared Libraries, first draft

[Sean Middleditch]

On Fri, 2004-11-05 at 11:38 +0000, Scott James Remnant wrote:
> This is actually a rarer case than it seems, often you want to
> deliberately force people into always using the latest development
> version of your library ... in which case it makes more sense to make
> them hard to parallel install.

This man deserves no cookie.

It has nothing to do with development.  It has to do with the users.  By
making your libraries hard (or impossible) to parallel install, you
screw over the users, who cannot deal with this scenario until someone
codes, packages, and installs updates for *all* affected applications.

> 
> 
> Header versioning isn't required ... if you correctly maintain backwards
> compatibility within a major version you don't need it.  Applications
> simply use whatever versions of library they require and check the
> headers declare them (or pkg-config knows the version is recent enough)
> in configure.ac

Within a major version, no.  GTK+, for example, puts the headers for GTK
2.6 in include/gtk-2.0.  I personally think it's silly to put the .0 on
there, but it doesn't really matter.  The header versioning is
incredibly important when you do break API compatibility (and, thus,
change the major version) because without it, you can no longer develop
against two versions of library.  Which is necessary in the real world,
no matter how much the library developer might want to force people to
upgrade.  Recoding old, large apps is expensive in terms of time (and
thus money) and it is often quite acceptable to just leave them using an
older library version.  The same developer might have a newer app using
a newer version of the library.  The developer needs to be able to make
updates and recompile binaries for both applications.

> Structure size changes are actually far less of a problem than you make
> out.  Structures are almost never passed-by-value into a function, and
> rarely used-by-value in another structure.

Wrong again.  Application code will often have something like:

struct library_foo my_foo;

Now that app brakes when linked against a version of the library with a
different library_foo size, independent of whether the struct is passed
by value - as soon as some library code tries to access non-existent
members of the struct, corruption or crashes occur.

> 
> 
> Scott
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg