On Fri, Apr 14, 2006 at 01:50:54PM -0700, Philip Brown wrote:

> b) the package wants to take advantage of some kind of library or
> interface that is only availlable on solaris 10.  In the free
> software world, this almost never happens; free software usually
> takes advantage of other free software, not differences between
> solaris 8 and solaris 10.

Unfortunately this does happen.  In fact, it just happened in the last
couple of weeks: Casper integrated the mkstemps family of functions
into libc.  By itself, this would be uninteresting - an application or
library either requires this function or it doesn't.  If it does, that
software would simply fail to work on builds which don't offer the
function.  However, the wrinkle here is the same one that appears
elsewhere - the assumption that the build environment and the runtime
environment will be the same.  For that reason, a great many Free
Software components ship with their own local, private copies of a
surprisingly large array of standard library functions.  Worse still,
these are usually static-linked into the resulting binaries.

The result in the above case is that the actual contents of the
binaries changed according to the build environment.  This is fine in
one direction; there's no guarantee that binaries built on Solaris N
(or, in this case build N) will work on N-1.  But in the other
direction, the choice to include these varied private static libraries
makes it impossible for the older software to take advantage of
improvements in the standard system libraries.  The impact can range
from mere unnecessary code (if the two implementations are compatible
and equally performant) to missed performance opportunities (for
example, not using libmd5 fails to take advantage of sun4v
optimisations) to severe breakage.

You can claim this is really just an indictment of static linking, and
it is.  But when we're talking about a class of software which
historically makes bad assumptions about the relationship between its
build and runtime environments, and tends to duplicate standard
library functions locally, the problem goes well beyond that.  In many
cases, there are real advantages to building on a newer release,
simply because of the way autotools work and the way the software is
architected.

Finally, let's not forget that OpenSolaris - including ON, which
contains most of the libraries which would offer the new features of
interest - *is* Free Software.  So what I'm describing here is
actually "free software ... tak[ing] advantage of other free
software."  And in fact you can see exactly the same thing on any
other operating system, Free or otherwise.

-- 
Keith M Wesolowski              "Sir, we're surrounded!" 
Solaris Kernel Team             "Excellent; we can attack in any direction!" 

Reply via email to