[https://web.archive.org/web/20190205035640/equi4.com/images/tclkit.gif]
A '''[https://code.google.com/archive/p/tclkit/%|%Tclkit]''' Is an executable
[Tcl] interpreter that can be combined with a [starkit] to produce a
[starpack].
** See Also **
[basekit]: A Tclkit provided Any executable that is designed to be combined with a [starkit] to form a [starpack]. Tclkit is one example.
[Tclkit Mobile]: Tclkit on a PDA.
[Differences between tclkit and tcl]:
[The (Few) Differences between Tcl and Tclkit]:
[How do I use a .kit file?]:
[http://www.equi4.com/swisskit.html%|%Swisskit]: An elaborate build of Tclkit Lite for Mac OS X.
[Wikit Command Line for Windows95]:
[Tclkit Kitgen Build System]: A tclkit based on vlerq and metakit.
[http://www.beedub.com/book/4th/Starkit.pdf%|%Tclkit and Starkits (pdf)]: A sample chapter on [Brent Welch%|%Brent Welch's] site from his book, [Book Practical Programming in Tcl and Tk%|%Practical Programming in Tcl and Tk].
[Using zip files like a .kit file]: Prefixing a zip file with a self-extractor stub results in something like a .kit file.
[LUCK]: Lean Undroidwish Construction Kit (undroidwish/vanillatclsh/vanillawish) for different platforms. The executable can be unzipped with standard zip tools to extract the packages (easy way to get precompiled librairies).
** News **
[http://www.linux-magazine.com/Issues/2013/148/Tclkit%|%Motorized Scripts], Klaus Kröll, Linux Magazine, 2013-03:
** Description **
A '''Tclkit''' is a single executable file that contains a Tcl interpreter and
the startup scripts and support libraries needed to access a [starkit] bundled
together with the Tclkit into a a [starpack]. A Tclkit can also be also be
used as a [tclsh] workalike.
The original tclkit contained exactly [Metakit] or [vlerq], [zlib], [tclVFS],
[incr Tcl], and optionally Tk. Various Tclkits are available and ready to use
on various platforms, including many [Unix], [Microsoft Windows%|%Windows], and
[MAC OS X] systems. For example, [TclKit Lite] is a Tclkit that avoids
[Metakit] and instead uses a library that avoids [C++] and also removes [incr
Tcl]. [dqkit] is yet another Tclkit.
Some Tclkits load [Tk] so that they are useful as either a [tclsh] or [wish].
On [Microsoft Windows%|%Windows] this dual use is not possible, and there is a
separate ''tclkitsh'' to run a command-line tclsh only system. On Macintosh
(prior to MacOS X), there is only a [GUI]-based wish version.
** Documentation **
[https://github.com/patthoyts/tclkit/tree/master/tclkit%|%README] ([https://code.google.com/archive/p/tclkit/%|%alternate]): A short introduction to Tclkits on the home page for the original Tclkit project.
[http://www.equi4.com/tclkit/docs.html%|%Tclkit Documentation]: Information about tclkits as well as pointers to other useful pages of information.
[http://code.google.com/p/tclkit/wiki/BuildingTclkit%|%Building Tclkit]:
[http://web.archive.org/web/20010117031600/http://www.zdnet.com/devhead/stories/articles/0,4413,2643240,00.html%|%Tclkit solves problems]: A magazine article that introduces uses of Tclkit, and especially its [VFS] capabilities, as a deployment solution.
** Community **
[http://groups.google.com/group/starkit%|%mailing list]: For TclKit and StarKit issues.
** Resources **
[http://www.equi4.com/pub/tk/tars/%|%equi4.com/pub/tk/tars]: The source for [kitgen] and the various other pieces that go into a tclkit or tclkit-lite.
[https://bitbucket.org/ihmin/tclkit/%|%https://bitbucket.org/ihmin/tclkit%|%]: Prebuilt binaries for windows machine.
** Tclkit Build Tools **
[http://kitcreator.rkeene.org/kitcreator%|%KitCreator Web Interface], by [Roy Keene]: Configure your own Tclkit for different platforms, with several additional packages like Tcllib, tDOM, TLS, TclUDP, etc, wait for the [KitCreator] online service to build it, and finally download it. Seems to support newer (latest?) versions of tcl.
[KitCreator]: A build environment to create a tclkit-like executables.
[http://www.rkeene.org/devel/kitcreator/kitbuild/nightly/%|%KitCreator nightly builds]: As of 2021-06-12, provides 8.5.19, 8.6.11, and fossil trunk builds for various platforms.
[kitgen], by [Pat Thoyts]: A system for creating Tclkits.
[http://www.tcl3d.org/html/appTclkits.html%|%TCL3D Kits]: The [TCL3D] project has TCL8.6.0/1 starkits with some source modifications.
** Tclkits (most up-to-date first) **
[http://tclkits.rkeene.org/fossil/wiki/Downloads%|%TclKits], by [Roy Keene]: As of 2022-02-04, provides 8.5.17 through 8.6.12 for various platforms. Roy is active in the [Tcl Chatroom], and usually happy to help troubleshoot TclKit issues.
[http://kitcreator.rkeene.org/fossil/wiki?name=Downloads%|%KitCreator downloads] by [Roy Keene], using [KitCreator]: Provides nightly builds of Tclkits containing various versions of Tcl. As of 2022-02-14, the most recent manually-built kits are 8.6.12 (Windows 32, Windows 64,) 8.5.17 (Windows 32, Windows 64, Mac OS, RHEL5, Solaris). KitCreator supports cross-compiling Tclkits.
[https://sourceforge.net/projects/twapi/files/Tcl%20binaries/%|%TWAPI Kits]: The [TWAPI] project provides 8.5.17 and 8.6.3-8.6.12 windows Tclkits with and without twapi. They also support the sdx icon import functionality.
[http://rkeene.org/projects/tcl-tutor/starkit2exe/customkit.rvt%|%CustomKit]: by [Roy Keene]. As of 2013-03-20, the latest builds are 8.5.11 (Solaris), 8.5.10 (Win32), and 8.5.9 (Mac OS X)
[ActiveTcl%|%ActiveTcl basekit]: ActiveTcl includes basekits with each distro release that mirror the core release of the dist. basekits are found in the bin directory
[ODIE]: Includes a so-far-not-very-user-friendly system for generating zip-based Tclkits.
[cookit]: Uses [cookfs].
[http://code.google.com/p/tclkit/wiki/TclkitDownloads%|%Tclkit download matrix]: The original Tclkit. Provides 8.5.9 and older for various platforms.
[http://code.google.com/p/tclkit/downloads/list%|%Tclkit complete list]: The original Tclkit. Longer listing of available kits providing 8.5.9 and and older for various platforms.
[http://web.archive.org/web/https://www.zolli.fr/tclkit-darwin.php%|%Tclkit aqua x86_64 builds for Mac OS X], by [David Zolli]: Currently provides versions 8.6.7 and 8.5.19.
[http://web.archive.org/web/https://www.zolli.fr/tclkit-darwin.php%|%Tclkit aqua x86_64 builds for Mac OS X], by [David Zolli]: Provides [KitCreator] builds of 8.6.7 and 8.5.19.
[Tclkit Kitgen Build System]: As of 2016-04-11, 0.4.9 provides 8.6.6 for various platforms
[http://www.patthoyts.tk/tclkit/%|%bleeding-edge builds], by [Pat Thoyts]: Look to the "files" section near the bottom of the page to find links to pages containing, as of 2013-03-20, 8.5.13 (Windows), 8.5.10 (Linux), 8.6b1.2 (Android), 8.5.7 (Solaris). 8.6.0 kits (Windows, Linux, Mac) built with Pat's version are available at that [http://www.tcl3d.org/html/appTclkits.html%|%Tcl3D site].
[Tclkit Lite]: Like Tclkit, but with fewer extensions included.
[Tclkit Mobile]: A port of Tclkit + [Tkcon] to certain PDAs.
Tclkit-X11 (Mac OS X only): Like Tclkit but with Tk/X11 in place of Tk/Aqua; part of the [TclTkAquaBI] distribution for [Mac OS X].
[TixTclKit] (Windows only): A different set of extensions including [Tix] and Windows-specific tools.
[Dqkit]: A much larger set of extensions, including [BLT].
[kbskit]: A build environment for creating either tclkit-like or tclkit lite-like executables (slightly different, but intended to be similar).
[tcltkaquabi]: Tcl/Tk Aqua Batteris Included. Includes a single-file Wish program similar to a basekit
[Tclkit Lite]: A light-weight variant of Tclkit.
[Wize - Wish Integrated Zip Executable]: Like Tclkit, with a compiler and a lot of goodies.
The following table lists the package version numbers for the basekits above.
The version numbers and availability come from the latest version available at
the time of writing.
[[anyone want to build a table that lists what extensions are in each basekit?]]
Legend:
* ''varies'' - Indicates that the value varies depending on the version of some other package (usually the version of Tcl)
* ''same'' - Indicates that thet value is the same as the nearest filled in value leftwards
* ''(opt)'' - Indicates that this Tclkit is available with and without this package
* ''same as Tcl'' - Indicates that the value is the same value as the version of Tcl
* ''Win-only'' - Indicates this is only supplied when being built for Microsoft's Windows platform
* ''???'' - Indicates that this package looks like it should be available, but is not.
%| | ActiveTcl | Tclkit | Tclkit Lite | Tclkit Mobile | Tclkit-X11 | TixTclKit | Dqkit | kbskit(*bi) | KitCreator | Wize |%
&| '''Tcl''' | 8.4, 8.5, 8.6, | 8.4, 8.5 | 8.4, 8.5 | | | 8.4 | 8.4, 8.5 | 8.5, 8.6 | 8.4, 8.5, 8.6 | 8.5 |&
&| '''Tk''' | ''same as Tcl'' | ''same'' | ''same'' | | | ''same'' | ''same'' | ''same'' | ''same'' | ''same'' |&
&| '''http''' | ''varies'' | ''varies'' | ''varies'' | | | ''varies''| ''varies'' | ''varies'' | ''varies'' | ''varies'' |&
&| '''msgcat''' | ''varies'' | ''varies'' | ''varies'' | | | ''varies''| ''varies'' | ''varies'' | ''varies'' | ''varies'' |&
&| '''opt''' | ''varies'' | ''varies'' | ''varies'' | | | ''varies''| ''varies'' | ''varies'' | ''varies'' | ''varies'' |&
&| '''platform''' | ''varies'' | ''varies'' | ''varies'' | | | ''varies''| ''varies'' | ''varies'' | ''varies'' | ''varies'' |&
&| '''tcl::tommath'''| ''varies'' | ''varies'' | ''varies'' | | | ''varies''| ''varies'' | ''varies'' | ''varies'' | ''varies'' |&
&| '''tcltest''' | ''varies'' | ''varies'' | ''varies'' | | | ''varies''| ''varies'' | ''varies'' | ''varies'' | ''varies'' |&
&| '''starkit''' | 1.3.3 | 1.3.1 | | | | 1.2 | 1.3.1 | 1.3.3 | 1.3.2 | 1.3.1 |&
&| '''Incr Tcl''' | no | 3.4 | | | | 3.3 | 3.3 | 3.4 | 3.4 | no |&
&| '''Metakit''' | 2.4.9.7 | 2.4.9.7 | | | | 2.4.9.2 | 2.4.9.2 | 2.4.9.7 | 2.4.9.7 | no |&
&| '''TclVFS''' | 1.4.1 | 1.3 | | | | 1.2 | 1.3 | 1.4.1 | 1.3 | 1.3 |&
&| '''Registry''' | ''Win-only'' | ''same'' | ''same'' | ''same'' | no | 1.1.1 | ''Win-only'' | ''same'' | ''same'' | ''same'' |&
&| '''DDE''' | ''Win-only'' | ''same'' | ''same'' | ''same'' | no | 1.2.1 | ''Win-only'' | ''same'' | ''same'' | ''same'' |&
&| '''PWB (8.4)''' | 1.1 | 1.1 | | | | 1.1 | no | no | 1.1 | no |&
&| '''Rechan''' | 1.0 | 1.0 | | | | 1.0 | 1.0 | no | 1.0 | no |&
&| '''Zlib''' | 1.0 | 1.1 | | | | 1.1 | 1.1 | 1.1 | 1.1 | no |&
&| '''Thread''' | 2.6.5 ''(opt)'' | ''Win-only''| | | | no | 2.6.3 ''(opt)''| 2.6.5 | 2.6.5 ''(opt)'' | no |&
&| '''Ttrace''' | 2.6.5 ''(opt)'' | ''Win-only''| | | | no | 2.6.3 ''(opt)''| 2.6.5 | 2.6.5 ''(opt)'' | no |&
&| '''Tclx''' | no | no | | | | no | ''???'' | (8.4) | no | 8.4 |&
&| '''TDBC''' | no | no | | | | no | no | 1.0b1 | no | no |&
&| '''BLT''' | no | no | | | | no | 2.4 | no | no | 2.4 |&
&| '''Tix''' | no | no | | | | 8.2 | no | no | no | 8.4.3 |&
&| '''SQLite''' | no | no | | | | 2.0 | 2.0 | no | no | no |&
&| '''SQLite3''' | no | no | | | | no | 3.3.4 | (3.6.20) | no | 3.6.13 |&
&| '''tclodbc''' | no | no | | | | 2.3 | no | no | no | no |&
&| '''Expect''' | no | no | | | | no | 5.43.0 | no | no | 5.44.1.11 |&
&| '''Itk''' | no | no | | | | no | 3.3 | (3.4) | no | no |&
&| '''Iwidgets''' | no | no | | | | no | 4.0.2 | (4.0.2) | no | no |&
&| '''mysqltcl''' | no | no | | | | no | 2.0 | no | no | no |&
&| '''Pgtcl''' | no | no | | | | no | 1.5 | no | no | no |&
&| '''tbcload''' | no | no | | | | 1.4 | 1.4 | no | no | 1.4 |&
&| '''Tktable''' | no | no | | | | 2.8 | no | (2.10) | no | 2.9 |&
&| '''tile''' | no | no | | | | no | 0.7.2 | no | no | no |&
&| '''autoscroll''' | no | no | | | | 1.0 | no | no | no | no |&
&| '''BWidget''' | no | no | | | | 1.6 | no | (1.8.0) | no | no |&
&| '''ctext''' | no | no | | | | 3.1 | no | no | no | no |&
&| '''cwind''' | no | no | | | | 1.3.1 | no | no | no | no |&
&| '''emu_graph''' | no | no | | | | 1.1 | no | no | no | no |&
&| '''ffidl''' | no | no | | | | ''???'' | no | no | no | no |&
&| '''gbutton''' | no | no | | | | 0.2 | no | no | no | no |&
&| '''iniparse''' | no | no | | | | 1.4 | no | no | no | no |&
&| '''mentry''' | no | no | | | | 2.6 | no | (3.3) | no | no |&
&| '''mkGeneric''' | no | no | | | | 1.3 | no | no | no | no |&
&| '''mkTables''' | no | no | | | | 1.0 | no | no | no | no |&
&| '''optcl''' | no | no | | | | 3.0 | no | no | no | no |&
&| '''snit''' | no | no | | | | 0.81 | no | no | no | no |&
&| '''tablelist''' | no | no | | | | 3.3 | no | (4.12) | no | no |&
&| '''tdom''' | no | no | | | | 0.7.8 | no | (0.8.2) | no | no |&
&| '''tdomhtml''' | no | no | | | | 0.1.0 | no | no | no | no |&
&| '''tkdnd''' | no | no | | | | 1.0 | no | no | no | no |&
&| '''tnc''' | no | no | | | | 0.3 | no | no | no | no |&
&| '''wcb''' | no | no | | | | 2.8 | no | (3.2) | no | no |&
&| '''Wikit''' | no | no | | | | 1.0 | no | no | no | no |&
&| '''winutils''' | no | no | | | | 0.8 | no | no | no | no |&
&| '''compiler''' | no | no | | | | 1.4 | no | no | no | 1.4 |&
&| '''TclCurl''' | no | no | | | | 0.10.5 | no | no | no | no |&
&| '''snack''' | no | no | | | | no | no | no | no | 2.2 |&
&| '''Img''' | no | no | | | | no | no | (1.4) | no | 1.2.4 |&
&| '''vu''' | no | no | | | | no | no | no | no | 2.1.0 |&
&| '''treectrl''' | no | no | | | | no | no | (2.2.9) | no | 2.2.8 |&
&| '''tkhtml''' | no | no | | | | no | no | no | no | ''???'' |&
&| '''Shaped''' | no | no | | | | no | no | no | no | 0.1 |&
&| '''Canvas3d''' | no | no | | | | no | no | no | no | 1.0 |&
&| '''fileutil::globfile'''|''varies''| | | | | | | | no | no |&
&| '''tclkitpath''' | 1.0 | | | | | | | | no | no |&
&| '''ActiveTcl''' | ''varies'' | no | | | | no | no | no | no | no |&
&| '''trsync''' | 1.0 (8.5.4 ActiveTcl) | no | | | | | | | 1.0 | 1.0 |&
** Check tclkit version **
[Ro]: 2002-09-06: The old way to check the version of Tclkit
======
puts $tcl_platform(vfs)
======
The “new” way to check the version of Tclkit
======
puts $::vfs::tclkit_version
======
** tclkit and kitten **
Another concept to check out is [Kitten], an example of packaging a group of
add-on extensions into a scripted document for use by other documents.
** Tclkit 8.4 Information **
'''The following section refers only to 8.4 - 8.5 has an [encoding dirs] command and 8.5 TclKit binaries include a broader range of encodings, missing only the larger Asian encoding files.'''
*** Encodings ***
Tclkit 8.4 only has a few Unicode encodings built-in. There is an experimental "librarypath" command that can be used to change/extend the places where Tclkit looks for encoding files [[...]]]
2002-03-18: update: here's a transcript to illustrate the new behavior, based
on a built-in Tclkit command called "librarypath":
======none
$ tclkit
% librarypath
/home/jcw/bin/tclkit/lib/tcl8.4
% encoding names
iso8859-2 utf-8 cp1252 ascii macRoman identity unicode iso8859-1
% librarypath /home/tcl/lib/tcl8.4
% encoding names
cp860 cp861 cp862 cp863 cp864 cp865 cp866 gb12345 cp949 cp950 cp869
dingbats ksc5601 cp874 macCentEuro macUkraine jis0201 gb2312 euc-cn
euc-jp iso8859-10 macThai jis0208 iso2022-jp macIceland iso2022
iso8859-13 jis0212 iso8859-14 iso8859-15 cp737 big5 euc-kr macRomania
macTurkish gb1988 iso2022-kr macGreek cp437 ascii
macRoman iso8859-1 iso8859-2 iso8859-3 koi8-r iso8859-4 macCroatian
iso8859-5 cp1250 iso8859-6 macCyrillic cp1251 koi8-u iso8859-7
macDingbats cp1252 iso8859-8 cp1253 iso8859-9 cp1254 cp1255 cp850
cp1256 cp932 identity cp1257 cp852 macJapan cp1258 utf-8 shiftjis
cp855 cp936 symbol cp775 unicode cp857
%
======
What this means is that you get only a few encodings as part of the packaged
tclkit, but to get more you can re-point it to another area containing an
appropriate "encoding/" subdirectory, and it'll use those.
The reason a special command is needed to do this is documented in [http://sourceforge.net/tracker/?func=detail&aid=463190&group_id=10894&atid=110894%|%Tcl Bug 463190], which is as yet not fixed.
'''Adding Encodings into TCLKit''' - if you want to add the full set
of encodings into your TCLKit, see the code at [http://www.wagsoft.com/Archive/AddEncodings.txt] (Mick O'Donnell Oct 2004)
----
VSU 2004-12-14: Unfortunately, the above solution (or the manual way described
at the official site [http://www.equi4.com/tkunicode.html]) does not work well
for the encoding which should be set as the system encoding. E.g., even after
adding all encoding files to tclkit, I still have:
======none
$ echo $LANG
ru_RU.KOI8-R
$ tclkit
% encoding system
iso8859-1
%
======
instead of the proper value:
======
$ tclsh
% encoding system
koi8-r
%
======
Because of this, Russian text in Tk comes out as an unreadable sequence of
iso8859-1 characters :(
[PT]: these kind of encoding issues should be solved since 8.5.6 and should
also be ok in 8.4.19 I believe.
----
[Matthias Hoffmann]: Under MS Windows in ''Console Mode'', you almost always
need to have the encodings '''cp437''' and/or '''cp850'''. So what does it
matter to include just these two more in '''tclkit-win32-sh'''?
** Tclkit Path Resolution **
The way in that Tclkit resolves paths is not well documented. This note is an
expansion on a communication from JCW to me (tomk) that helps explain the
situation.
In the following discussion I have created a test.vfs directory that contains a
bin and lib directory. I placed the [BWidget] package in the lib directory and
moved the bwidget demo.tcl file from the bwidget/demo directory to bin/main.tcl
in the test.vfs directory structure. The demo.tcl code normally sources other
files from the local directory, which meant that when I move the code to the
bin directory I had to modify the source path so that it was
../lib/bwidget/demo. This code worked fine during test, but when the code was
converted to an SD it failed, which lead to the communication provided below.
<JCW wrote>
When working with an unpacked SD, you can test and debug by doing something like:
======none
tclkit test.vfs/main.tcl
======
And to change to a new location in the tree, you can do:
======none
cd test.vfs/lib/bwidget/demo
======
But when running in packed mode, the "test.vfs" *dir* gets replaced by the name
of the SD, i.e. if you've called the SD "test.bin", then you're still running
with a current working directory that is outside the SD, but the *file* is
mounted and now looks like a dir, so you will have to do:
======
cd test.bin/lib/bwidget/demo
======
to get to the demo directory.
To get around this need to know how you're running things, you can do things
like this in the bin/main.tcl script:
======none
cd [file join [file dirname [file dirname [info script]]] lib bwidget demo]
======
Note that when the cwd is inside an SD, then things like [exec] work somewhat
differently, because everything outside the Tcl world has no idea of VFS.
To see what I mean, try the following:
======
$ tclkit
% cd tclkit/lib/tcl8.4
% glob *
...
% ls
...
% pwd
...
% exec sh -c pwd
...
======
[MHo]: Perhaps this link will give a little help on the exec-problem:
[http://wiki.tcl.tk/12168]. The routine automates the process of copying an
.exe out of the VFS to a temporary position and EXECing it from there.
----
[PT] 2003-05-01: The more recent versions of starkits can handle the
applications location rather better. To illustrate let us create a micro
starkit with hello.vfs/main.tcl containing:
======
package require starkit
set r [starkit::startup]
lappend r $::starkit::topdir [file dirname $::starkit::topdir]
puts $r
======
We can then create a starkit and starpack (sdx wrap hello.kit and sdx wrap hello.exe -runtime tclkitsh.exe) and try:
======none
> tclkitsh hello.kit
starkit U:/lib/tcl/hello.kit U:/lib/tcl
> .\hello.exe
starpack U:/lib/tcl/hello.exe U:/lib/tcl
> tclkitsh hello.vfs\main.tcl
unwrapped U:/lib/tcl/hello.vfs U:/lib/tcl
======
So as you can see - [[file dirname $::starkit::topdir]] is always the same, no
matter how it is run.
** Tclkit Questions and Problems **
What might cause a segfault on Linux (SuSE 8.0) when using the [Img] library
with Tclkit? Just to be sure that loading the shared lib out of the starkit
wasn't the problem, I have abstracted the problem to the following scenario:
I've created a test folder with just libimg* in it, and one folder above that I
have all the lib* files from the lib path of my Tcl installation. My test
program is as follows:
======
load libimg1.2.so Img
image create photo -file foo.jpeg
======
When I run the code in tclsh ([ActiveTcl] 8.4), everything works fine; I can
even put the image into a label and display it with pack. However, the exact
same program crashes Tclkit (latest available as of 4 August 2002) with a seg
fault. What am I doing wrong? Am I missing a shared library somewhere?
[unDees]
Try using the version of Tclkit at
http://www.equi4.com/pub/tk/newer/linux-i686.gz - there were a couple of
problems with the July builds that may be causing the problem. Let me know how
you go (via e-mail) and I can chase further - [stevel]
Thanks for the suggestion, Steve. First, I tried a later July build and at
least got a JPEG to load without crashing. But packing the resulting label
simply resulted in an empty window. So I tried the build from the "newer"
directory as of today (August 5). Now I'm back to the original problem--the
"image create" statement causes a segfault.
Can anyone replicate this error on Linux? I should add that the problem
doesn't happen on Win32.
Thanks in advance... [unDees]
[NEM]: I just noticed a message in the [Metakit] mailing list archives about
this problem. A possible work around might be to add some
======
catch {load blah/libjpeg.so}
catch {load blah/libpng.so}
======
lines before loading Img. This ensures that those libraries that are needed by
image are present. (search the archive for more info)
----
[emukang]: I also met the problem when using Img package on ipaq linux pda,
then I solved it by install another package, have a look of [Install tcl on
ipaq familiar linux PDA with Img package]
----
When you visit the Tclkit home page (mentioned above), you will find that it
was originally designed to be built using a series of tar files and a script
called [genkit]. [[That build mechanism has been replaced by a new script
called [kitgen].]]
I am finding that on my personal platform, the g++ compiler requires me to add
the directory where the g++ shared libraries reside to the LD_LIBRARY_PATH
environment variable before creating the executable. This weird configuration
fact (identified when attempting to run a C++ compiled app by the unable to
locate libstdc++.so error message), results in the genkit steps failing. Add
the appropriate directory/lib to your LD_LIBRARY_PATH variable, ensure it is
exported, and try again.
[AK]: I can confirm this for the solaris boxes I have access to.
[jcw]: another gotcha I ran into on Solaris was the need to set CC in the env
to "gcc"
----
Only one instance of Tclkit/Starkit??
[CT]: I am just starting to read up on kits as I plan on moving over to them
exclusively with all my MetaKit database applications. One question
that is burning is this: 'Is Tclkit setup in such a way to only run one
instance of a particular starkit?' I ask this because some of my
applications will suffer as a result of more than one process trying to
update the same metakit views as metakit does not support concurrency
yet.
----
[LES] 2004-01-07: Pray tell. I have so many times seen the Tcl community
marvel and drool at the Starkit concept, but isn't [TixTclKit]
[http://www.microemacs.de/tcltk_tixtclkit.html] a MUCH better way to run a tcl
script (unless you have Tcl/Tk fully installed, of course), since it features a
single executable and so many extensions, adding up to some sort of
'''batteries-included single executable'''? Pray tell. Enlighten me, my kind
lord.
[CT]: I believe that TixTclKit is a windows only build of the TclKit. Besides
that, from what I can tell, Starkits are the actual application that you want
to run in/with the TclKit, so TixTclKit would still need your application in
the form of a Starkit in order to be useful unless you rebuilt the TixTclKit
itself with your application embedded in it already. Not 100% sure if all my
assumptions are correct but that's what I can gather anyway. Cheers.
[LES]: No, you can run '''TixTclKit.exe somescript.tcl'''. No starkits required.''
[jcw]: Tclkit includes very few extensions because it is aimed to be
infra-structure (and be equivalent on two dozen or so platforms). A BI version
is wonderful, but a separate topic IMO - if I had made Tclkit to include more
extensions, I would have had to continuously track and maintain every build of
them. The [kitten] approach is another way to do "BI", albeit as 2 files.
FWIW, I very much like Detlef Groth's TixTclKit, and Windows really is a key
platform to aim for, but they are not addressing the same issue. Note that
tclkit vs. tixtclkit is not really a big deal: tixtclkit is tclkit with a very
nice set of extra packages added to it (unwrap+re-wrap). Both are
totally-effortless-to-deploy executables and both support starkits & starpacks
- which is the key point of all this.
[LES]: Hmmm... "the key point of all this" says you. I would like to declare
that the whole point of the starkits were never too clear to me. Sometimes I
want to share one of my programs with someone, almost invariably someone who
doesnt' know anything about Tcl and I say: "you can either download and install
12-Mb [ActiveTcl] or '''single-file''' 2-Mb [TixTclKit] to run my .tcl file".
And guess what happens most frequently. And I feel '''confident''' telling
people to use [TixTclKit] because I know it supports even more extensions than
I am ever likely to use in all my lifetime's programs. It '''will''' run my
script, you can be sure. So [TixTclKit] makes everyone's lives easier. If
that's not what starkits are for, what is it then?
[jcw]: Your argument only applies to single scripts. For anything more
substantial than that, starkits make my life a lot simpler. Note that
TixTclKit + yourstarkit == Tclkit + yourstarkit-with-extensions. Two files
either way. You seem to be arguing against ActiveTcl, not Tclkit.
Even with single scripts, I often use starkits to get extra compression. The
following are equivalent:
======none
tclkit blah.tcl
======
======
sdx qwrap blah.tcl
tclkit blah.kit
======
But hey - it's just a technology and it's OSS and it's optional. No one is
forcing you to use tclkit or starkits :)
[LES]: I am not arguing against ActiveTcl. ActiveTcl has got most of the
extensions. My only complaint is that it is a large download. I am arguing
against Tclkit because it doesn't support the extensions, and you're also left
with the extra work of building the starkit. It may not be that tough, but it's
an additional step. With [TixTclKit], my friends can run any of my bare-bones
.tcl scripts without any extra tweaking, either on my or their side. Again: I
don't see what big advantage there is in employing starkits instead of anything
else. I know no one is forcing me to use them, but I sure would like to see
what so many others claim to see...
[LV] LES, your argument works for you because you have chosen to only use
extensions that exist within TixTclKit. Other people choose to only write apps
which reside inside TclKit itself, or even within [dqkit] (another attempt at a
[Batteries Included] single file. The bottom line is that the extensions that
you need/use/find useful/find bearable and the ones that another developer
finds useful may not always be the identical set. In that case, the TixTclKit
developer then finds herself where the TclKit developer has been all along -
determining how best to package the additional requirements so that the
application can be shipped. To include every possible extension then results
in a single file download that approaches the size of ActiveTcl - which most
agree is too large for the average user to mess with.
So what's the solution? It's hard to say. In the case of specialized tclkits
like TixTclKit, applications using them will only run on on platforms where the
custom runtime tclkit has been built. In the case of the standard tclkit, the
developer either makes use of a tool such as [TDK], which has an interface for
creating starkits with the developer specified extensions included, or they
manually construct the pieces, develop/copy and debug the cross platform code
loading code, etc.
[MR]: I don't know about you, but not too many of my programs consist of a
single .tcl file, rather than lots of .tcl files, lots of image, help, and
other associated data files, as well as not only fairly broadly used extensions
(both Tcl and C) but also usually some C extensions pretty specific to my app.
I can shove all that in one file and ship it to people.
[LES]: exactly 5 months later: I just read the discussion above and I am not
happy with it because I didn't express myself well at all. Or maybe I didn't
really know what I was talking about. Likely the latter. I finally see why
starkits are so appreciated by the Tcl community. Though I still think that
[TixTclKit] kicks some considerable ass. Now I just wish Tcl and starkits were
as common and widespread as the Java runtime and .jar files.
[CMcC]: Since tclkit is a starkit, shouldn't one be able to take the standard
tclkit and add the packages one wants using [sdx]? That would solve [LES]'s
problem by making it very easy to roll one's own tclkit, for a single file
executable distribution.
----
Obviously a beginner's question: How can I run a ascii-only tcl script using
tclkit (on Windows)? Currently when I try to do this, a window pops up instead
of writing my output to the command prompt screen.
[jcw]: On Windows, use "tclkitsh.exe", which is a different download. Tclkit = wish, tclkitsh = tclsh
You can find this on the [http://www.equi4.com/0%|%Equi4 site] but I am not
sure that it is a recent version.
Alternatively, add
======
catch {console show}
======
to your script which throws up a console behind the tk window.
----
[MNO]: Does anybody else see the following error when trying to load Tk in a
tclkit on Solaris?
======none
bash% ./tclkit-solaris-sparc
% package require Tk
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
Atom id in failed request: 0xed
Serial number of failed request: 13
Current serial number in output stream: 16
======
Other X programs work fine (e.g. xterm, xdpyinfo etc.). The X server is a
recent Cygwin one, running under Windows 2000, if that makes a difference. ldd
on the tclkit gives the following:-
======none
bash% ldd tclkit-solaris-sparc
libdl.so.1 => /usr/lib/libdl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/FJSV,GPUSC-M/lib/libc_psr.so.1
======
[jcw] 2005-03-05: See [http://mail-index.netbsd.org/current-users/2005/02/21/0003.html%|%problems with some X applications, netbsd "currnet-users" mailing list, 2005-02-21] for a solution (it worked for me).
[LV] I use version
======none
2004/02/02 12:54:25 11180-37925 tclkit
======
of tclkit on SPARC Solaris 8, and I do not see the behavior you describe.
[MNO]: Thanks, Larry - I'll take a look into my X server, it sounds like the problem may lie there.
It looks, from googling around a bit, that the problem is in the OpenSSH X
forwarding. Interestingly, it seems to be intermittent - tclkit will
repeatedly fail with the above error for a while, then suddenly, in the same
session, it will start working.
----
How does a Tclkit compare in size to a file created using [Python]'s freeze?
[LV]: you probably want to compare a [starpack] to the frozen program. A
Tclkit isn't a stand-alone application, but instead a stand alone tcl
interpreter. A starpack would be a tclkit and application, ''frozen'' into a
single file.
[RLH]: I know that a Starpack is smaller than a Par/pp [Perl/Tk] application.
I have the same application coded for Tcl/Tk and Perl/Tk and the Perl one is
twice the size. [VK] ... and twice the speed:
[http://perlmonks.org/?node_id=426089%|%Comparing Tcl::Tk and perlTk WRT speed, perlmonks.org, 2005-01-28]
----
[LV]: Just a note if you are encountering a message similar to this when
attempting to execute a [starkit]:
======
extra characters after close-brace
while executing
"return [uplevel 1 [list [namespace origin mcunknown] $Locale $src {*}$args]]"
======
The problem is this - the code within the starkit requires a newer version of
Tcl than your tclkit provides. This means that you should check the tclkit
download matrix for an update, or in the worse case, have to build a new
version yourself.
----
[MG]: I just read the license on the Tclkit website:
''The Tclkit-specific sources are license free, they just have a copyright. Hold the author(s) harmless and any lawful use is permitted.
This does not apply to any of the sources of the other major Open Source Software components used in Tclkit, which each have very liberal BSD/MIT-like licenses:
IncrTcl, Metakit, Tcl/Tk, TclVFS, Zlib ''
I hadn't realised they were all included as separate things - I'm assuming that
if you wrap to a .exe then unwrap, you can remove some and rewrap (with
IncrTcl, anyway). Are all of the others required, if you aren't specifically
'package require'ing them?
[LV]: First - if your concern is reducing the size of the tclkit portion of
the exe, look to the tclkit-lite, which is an attempt to reduce things to a
signifcantly smaller footprint. Secondly, in the original tclkit, certainly tcl
is required, metakit, tclvfs, and I believe zlib. Tk isn't required if your
application doesn't specifically require it, nor is incr tcl.
----
[LV]: Just this week I went to the site listed at the top of this page to
download a tclkit for Linux. I took that version and tried it out on the Ubuntu
system at home. Alas, tclkit failed, claiming it could not locate the
appropriate g++ library.
I was, however, able to get the starkit in which I was interested to run using
the ActiveTcl 8.5.7 tclsh8.5 executable, so if someone else runs across the
same issue, they might try that approach.
----
[garden] 2011-07-23 06:51:29: It can't be simpler... but it simply does not
work! Ubuntu 11.4, from a terminal, in the folder where tclkit858 is located. $
./tclkit858 myapp.tcl $ That is: nothing happens It works perfectly on
Ubuntu10.4
----
[MHo] 2012-10-31: All Tclkits I can find are relatively outdated.
Unfortunally, I'm not able to produce binaries by myself.
[RZ]: You could try one from
http://sourceforge.net/projects/kbskit/files/kbs/0.4.3/
[MHo]: Thanks, I'll try. Three comments:
* The executable are somewhat big. Are they UPX'd?
[RZ]: no
* Are the Windows .EXEs 32bit oder 64bit?
[RZ]: compiled under msys/mingw on 64bit Windows7
* In WindowsNT_kbsmk8.5-cli.exe, e.g., I see a dependency on
* c:\programme\mingw\bin\libstdc++-6.dll - does this mean I have to have
* this DLL to run the Kit?
[RZ]: I'm no expert under windows, but you could try the *kbsvq* versions.
*kbsmk* versions use metakit as internal database and require C++ compiling.
*kbsvq* use vlerq as internal database and only need a C compiler.
[MHo]:
* Since I could execute under Win XP 32 bit: the windows versions are 32bit EXEs.
[AMG]: Watch out, libstdc++-6.dll isn't the only dependency. I grabbed this
file from MinGW
[http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.7.0-1/libstdc%2B%2B-4.7.0-1-mingw32-dll-6.tar.lzma/download]
and put it in the same directory as the *mk* executable, only to find that it
also wants libgcc_s_dw2-1.dll, which can be found here -->
[http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.7.0-1/libgcc-4.7.0-1-mingw32-dll-1.tar.lzma/download].
Thankfully, these are the only two DLLs I needed in order to get it to work.
Oh, you'll need something that groks lzma, e.g 7zip
[http://sourceforge.net/projects/sevenzip/files/7-Zip/9.20/7z920.exe/download].
[MHo]: If this is the case, these kits are ineligible for me since it negates
one of the biggest advantage of tclkits, the "no-install-approach". I just took
a quick look at active state's basekits, they only rely on standard windows
dlls.
[AMG]: I know, it's irritating, but at least you can put the DLLs in the same
directory as the EXE and it'll work. Or just use the [Vlerq] (*vq*) version.
I don't know why the [Metakit] version (*mk*) wasn't statically linked to the
C++ libraries.
----
[MG]: What's the best way to obtain an [ActiveTcl] basekit? I'm currently
building Starpacks using Tclkits from the Google Code site, but the versions
aren't that recent. However, the ActiveState downloads seem to all be for
installers for different platforms, and I'm trying to build Starpacks for
multiple platforms from a Windows machine, so they're not really useful for me.
[stevel]: Download ActiveTcl on each platform you are interested in and
collect the basekit for each. You can generate starpacks for any supported
platform, on any supported platform. If you don't have access to a particular
platform consider using the [KitCreator] nightly builds.
[HaO] 2014-01-10: (Temporary posting, please delete if obsolete) I personally enjoy the 'classic' [upx]-packed kits.
Links are currently also on [kitgen].
----
[AMG]: What are my options for obtaining or building an 8.6.6 (or newer) Tclkit for Windows 2000? [Pat Thoyts]'s most recent offering does not work on Windows 2000. It immediately exits with no error information given. I should note that I do not require Tk and in fact prefer that it not be statically linked into the Tclkit.
Update: [http://kitcreator.rkeene.org/fossil/wiki?name=Downloads%|%KitCreator] (linked above) from [Roy Keene] works on Windows 2000. Huzzah! Now if only I didn't have to use Windows 2000...
<<categories>> Wikit | Tclkit | Application | Distribution