From owner-freebsd-ports  Thu Oct 31 06:33:19 1996
Return-Path: owner-ports
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id GAA10080
          for ports-outgoing; Thu, 31 Oct 1996 06:33:19 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA10071;
          Thu, 31 Oct 1996 06:33:13 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.2/8.8.2) with ESMTP id WAA09452;
          Thu, 31 Oct 1996 22:33:01 +0800 (WST)
Message-Id: <199610311433.WAA09452@spinner.DIALix.COM>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Eric L. Hernes" <erich@lodgenet.com>
cc: asami@freebsd.org (Satoshi Asami), ports@freebsd.org
Subject: Re: scotty build failure 
In-reply-to: Your message of "Thu, 31 Oct 1996 08:04:27 CST."
             <199610311404.IAA28331@jake.lodgenet.com> 
Date: Thu, 31 Oct 1996 22:33:01 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-ports@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

"Eric L. Hernes" wrote:
> Satoshi Asami writes:
> >Here's another one that just broke.  The file in question in
> >/usr/local/lib is named "tnm2.1.3.so.1.0".  (But don't we need a "lib"
> >in front of library names?)
> 
> If the linker operates on it, yes.  As far as I recall, only tcl's
> `load' operates on this one.  The author's idea was to install this
> stuff and use it by setting the env var TCLLIBPATH to point
> to the tnm2.1.3/ and tkined1.4.3/ directories.  My `solution' was
> to make a shell wrapper to set this crap.
> 
> I'll fix the build.  The library name crap was/is the brainchild of
> the author and it appears that no one is supposed to link against it,
> just use it as tcl library.  Is this something that I should look into
> and try to fix; or just let it be as `flawed by design', but working
> as the author intended?

Hmm, please look more closely at the impact of the change that I did to 
TCL_SHLIB_SUFFIX='.so.1.0' in tclConfig.sh.  To my mind, this is 
unambigious since it's "SHLIB", meaning library, not "shared object".  I 
was trying to avoid having to do a large, ugly patch to the expect 
configure script which was expecting TCL_SHLIB_SUFFIX to mean "the bit you 
whack on the end of a shared library filename so that ld/rtld can link 
with it".

There are other mechanisms to generate the shared library name, if the 
change that I made to tclConfig.sh is wrong, it needs to come out and 
expect needs to be fixed to use the alternate mechanism that knows about 
shlib versioning.  IMHO, the naming and documentation of the intent of the 
variables in tclConfig.sh could be a lot better.

Cheers,
-Peter