From owner-cvs-ports  Mon Dec  9 04:33:44 1996
Return-Path: <owner-cvs-ports>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id EAA01815
          for cvs-ports-outgoing; Mon, 9 Dec 1996 04:33:44 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA01810;
          Mon, 9 Dec 1996 04:33:34 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id UAA10638;
          Mon, 9 Dec 1996 20:31:39 +0800 (WST)
Message-Id: <199612091231.UAA10638@spinner.DIALix.COM>
To: asami@freebsd.org (Satoshi Asami)
cc: thomas@ghpc8.ihf.rwth-aachen.de, CVS-committers@freefall.freebsd.org,
        cvs-all@freefall.freebsd.org, cvs-ports@freefall.freebsd.org
Subject: Re: cvs commit: ports/graphics/ImageMagick/pkg PLIST 
In-reply-to: Your message of "Mon, 09 Dec 1996 01:54:10 PST."
             <199612090954.BAA00918@silvia.HIP.Berkeley.EDU> 
Date: Mon, 09 Dec 1996 20:31:39 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-cvs-ports@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Satoshi Asami wrote:
>  * I noticed that testing display from the WRKSRC doesn't work, because
>  * it tried to pick up libMagick.so.3.7.7 which is incompatible with
>  * 3.7.8. Running ldconfig or setting LD_LIBRARY_PATH appropriately fixed
>  * that. I still have older versions of libMagick left over at home and
>  * haven't seen a problem yet.
> 
> Ok, so they are incompatible.  Is that one direction only?  (I.e., do
> old binaries work if they are fed libMagick.so.3.7.8?)
> 
> Also, you didn't say how it "doesn't work".  Does ld.so correctly
> print out a warning ("shlib minor >= 8 expected, only found 7, using
> it anyway" or some such) or does it just bomb on you with a core dump
> or mising function?
> 
> If it is the latter, that means the third digit is ignored by
> ldconfig/ld.so.

Yes.  The third digit is totally ignored when comparing compatability.  It
simply takes the highest "micro" revision available.

Ie: if you link with libfoo.so.3.3.3, it only records 3.3 in the headers,
and will link with anything starting with
libfoo.so.3.(anything >= 3).(highest available).

eg: it would be quite happy with libfoo.3.91.123, and just as happy with
libfoo.so.3.3 or libfoo.so.3.3.0.  Note that ld.so will always use the
highest "minor" revision.  ie: it'll use libc.so.2.2 in preference to
libc.so.2.0, even if it was initially linked with libc.so.2.0.  This is
another thing that our compat dists have got wrong on a most occasions..
installing libc.so.2.0 is a waste of disk space when libc.so.2.2 is
available.
 
> Satoshi

Cheers,
-Peter