From owner-cvs-ports  Fri Aug 18 04:18:07 1995
Return-Path: cvs-ports-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id EAA17162
          for cvs-ports-outgoing; Fri, 18 Aug 1995 04:18:07 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id EAA17135
          ; Fri, 18 Aug 1995 04:18:01 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id EAA04848; Fri, 18 Aug 1995 04:17:53 -0700
Date: Fri, 18 Aug 1995 04:17:53 -0700
Message-Id: <199508181117.EAA04848@silvia.HIP.Berkeley.EDU>
To: jkh@time.cdrom.com
CC: CVS-commiters@freefall.FreeBSD.org, cvs-ports@freefall.FreeBSD.org
In-reply-to: <25181.808743200@time.cdrom.com> (jkh@time.cdrom.com)
Subject: Re: cvs commit: ports/lang/tcl74/pkg PLIST
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: cvs-ports-owner@FreeBSD.org
Precedence: bulk

 * >   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 not a problem for programs in the main source tree, because
they are all updated simultaneously when a system library changes.
But that is not true for the ports tree, and the only way to make it
possible to have both versions selectable is to change the basename of
the library.

And if you think this (change to tcl and tk) is ugly and would make us
incompatible with the rest of the world, don't worry too much, John
Ousterhout has named his new static library "libtk4.0.a" (apparently
so that it can peacefully coexist with the 3.6 static lib).  Thus, the
"standard" tk ports should come with "-ltk4.0", and we should do is to
change it to "-ltk40".  Ditto for tcl.

Satoshi

P.S. Of course, if we could fix ld to allow a dot in the name, so that 
     we can use "libtk4.0.so.1.0" as the shared library name, it would 
     be even more "compatible", but that looks rather ugly, and it
     would surely screw up "ldconfig -r"'s output big time so I don't
     think we should do that.

     Cf. If you don't know what I mean, see how the "tk4.0" will fit
     in here....

     >> ldconfig -r | grep tk
        34:-ltk40.1.0 => /usr/local/lib/libtk40.so.1.0
        62:-ltk.3.6 => /usr/local/lib/libtk.so.3.6