From owner-cvs-ports  Fri Aug 18 04:44:18 1995
Return-Path: cvs-ports-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id EAA18261
          for cvs-ports-outgoing; Fri, 18 Aug 1995 04:44:18 -0700
Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id EAA18255
          ; Fri, 18 Aug 1995 04:44:12 -0700
Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id MAA10490; Fri, 18 Aug 1995 12:42:43 +0100
From: Paul Richards <paul@netcraft.co.uk>
Message-Id: <199508181142.MAA10490@server.netcraft.co.uk>
Subject: Re: cvs commit: ports/lang/tcl74/pkg PLIST
To: asami@cs.berkeley.edu (Satoshi Asami)
Date: Fri, 18 Aug 1995 12:42:42 +0100 (BST)
Cc: jkh@time.cdrom.com, CVS-commiters@freefall.FreeBSD.org,
        cvs-ports@freefall.FreeBSD.org
In-Reply-To: <199508181117.EAA04848@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Aug 18, 95 04:17:53 am
Reply-to: paul@FreeBSD.org
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 1654      
Sender: cvs-ports-owner@FreeBSD.org
Precedence: bulk

In reply to Satoshi Asami who said
> 
>  * >   Change library names.  This thing is not compatible with tcl-7.3 at
>  * >   all, so call it libtcl74.so.1.0.  Same for the static library.
> 
> (I asked about this on the ports list...guess you haven't made it back 
>  to there yet? ;)
> 
>  * Ack?!  Hmmm.  This kind of name mangling leads me to believe that
>  * we've got some fundamental problems in the way we look for shared
>  * libraries, or at the very least in how we're able to "lock" a given
>  * application to a library that it truly requires.  This certainly won't
>  * be the last such instance where backwards compatibility isn't
>  * maintained?
> 
> Yes, I think so too.  Essentially, the problem is this:
> 
> Suppose we have libtk.so.3.6 and libtk.so.4.0 in our ld search path.
> If we take an application that is already linked to one of them, it
> will run fine.  But if we want to link something that requires the
> lower-numbered version (3.6 in this case), there is no way to specify
> this, because all ld understands is -ltk and it will just use the
> highest numbered shared library (4.0 in this case).
> 

This is most definately a bug in ld.so, it should use the library with the
same major number as the application expects. Other libraries will
be incompatible, that's why the major number is different! It's OK to
use a higher minor number.

I think SunOS falls back to an older major number if the requested
library can't be found.

-- 
  Paul Richards, Bluebird Computer Systems. FreeBSD core team member. 
  Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
  Phone: 0370 462071 (Mobile), +44 1222 457651 (home)