Tcl Library Source Code

View Ticket
Login
Ticket UUID: ba3b0d913c430b5cb2182eedbea80eba8a6ac87a
Title: Allow specifying path to tclsh; pick better default tclsh
Type: Bug Version: 1.15
Submitter: anonymous Created on: 2014-06-11 11:38:55
Subsystem: general request Assigned To: aku
Priority: 7 High Severity: Severe
Status: Closed Last Modified: 2014-11-19 04:40:29
Resolution: Fixed Closed By: aku
    Closed on: 2014-11-19 04:40:29
Description:
Hello, I'm a developer with the MacPorts package management system.

As of version 2.3.0, MacPorts incorporates a copy of tcllib. It has come to our attention that tcllib has code to find a suitable tclsh program, but that when multiple tclsh programs are found, the one that it tries to use is not necessarily one that works:

http://core.tcl.tk/tcllib/artifact/b93d99315ce5f4758a13021bc708a54da766fd94

For example it was reported to us that a user had installed a 3rd-party tcl package which contained a 64-bit version (tclsh8.6-64) in addition to a 32-bit version (tclsh8.6), and the user's computer was 32-bit, but tcllib chose to use the 64-bit version, which won't work.

https://trac.macports.org/ticket/43809

I'm hoping a better mechanism can be found to locate a suitable tclsh. Maybe check first if one called just "tclsh" is available (which would find the version included with every version of OS X, which should work), or skip executables that don't pass a simple check, such as printing their version number.
User Comments: aku added on 2014-11-19 04:40:29:

And applied to Tklib as well,

Commit: http://core.tcl.tk/tklib/info/ba3b0d913c

This ticket is now done.


aku added on 2014-11-19 01:11:02:

The patch looks ok.

Tweaked the messaging a bit.

Applied with commit [262292fc92]. Pushed.

Keeping the ticket open until the same patch has been applied to tklib.


anonymous added on 2014-11-14 09:09:46:
Here is a patch that provides a --with-tclsh:


--- tcllib-tcllib_1_16/configure.in     2014-02-11 14:04:18.000000000 -0500
+++ tcllib-tcllib_1_16.new/configure.in 2014-11-12 23:42:03.000031000 -0500
@@ -10,8 +10,24 @@
 esac
 AC_SUBST(CYGPATH)
 
+AC_ARG_WITH(tclsh, [  --with-tclsh=FILE location of a working tclsh executable], with_tclsh=${withval})
+
 SC_SIMPLE_EXEEXT
-SC_PROG_TCLSH
+
+# allow user to override the tclsh we think we found
+if test x"${with_tclsh}" != x ; then
+    AC_MSG_CHECKING([for tclsh])
+    if "${with_tclsh}" </dev/null ; then
+        TCLSH_PROG=${with_tclsh}
+        AC_MSG_RESULT([manually set by --with-tclsh=$TCLSH_PROG])
+    else
+        AC_MSG_ERROR([No tclsh at place specified by --with-tclsh (${with_tclsh})])
+    fi
+    AC_SUBST(TCLSH_PROG)
+else
+    SC_PROG_TCLSH
+fi
+

aku added on 2014-06-11 18:22:49:
Ah! You are talking about the aclocal.m4 as part of Tcllib's configure(.in) code.
Had to look at the referenced artifact to understand.

Have to see if the tcl.m4 in the latest TEA is better in this regard.
(TEA_PROG_TCLSH).

Trying to run the tclsh ... makes sense.