itcl and USE_TCL_STUBS

[jlku...@gmail.com]

I've been using Tcl for the last decade or so with a simulator built as a static executable that can be sent to various remote linux clusters to run. As such I don't want to have to send libraries along with it. itcl and other packages have a configure file that doesn't conditionalize USE_TCL_STUBS on --enable-shared, and in fact, various files just set it. Every time I update to a new Tcl version, I have to edit these out. Is there some reason (1) USE_TCL_STUBS can't be controlled by configure, and (2) have it be dependent on whether or not you are building a static library?

[Don Porter]

The configuration restraint was added to fix this bug:

http://core.tcl.tk/itcl/info/9a1bd507bd

My limited understanding is that Itcl 4 is built on the TclOO facilities
and those facilities have been designed to be accessible only via
the stubs mechanism.

Your desire for a one-file executable distribution is a common one.
It is usually solved these days by one of the "kit" technologies.

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

[Hypnotoad]

On Tuesday, June 7, 2016 at 3:06:01 PM UTC-4, jlku...@gmail.com wrote:
> I've been using Tcl for the last decade or so with a simulator built as a static executable that can be sent to various remote linux clusters to run. As such I don't want to have to send libraries along with it. itcl and other packages have a configure file that doesn't conditionalize USE_TCL_STUBS on --enable-shared, and in fact, various files just set it. Every time I update to a new Tcl version, I have to edit these out. Is there some reason (1) USE_TCL_STUBS can't be controlled by configure, and (2) have it be dependent on whether or not you are building a static library?

I have posted a new TEA and a modified itcl that utilizes the new TEA to the various fossil archives.

The net effect is that Tcl extensions using the latest TEA now have an additional ./configure option --disable-stubs, but that flag is only honored when --disable-shared is also present. When --disable-stubs is true (or more accurately --enable-stubs is not true) the -DUSE_TCL_STUBS and -DUSE_TCLOO_STUBS (and for Tk extensions -DUSE_TK_STUBS) compiled flags will not be set.

[Kevin Kenny]

On Tuesday, June 7, 2016 at 3:06:01 PM UTC-4, jlku...@gmail.com wrote:

> I've been using Tcl for the last decade or so with a simulator built as a static executable that can be sent to various remote linux clusters to run. As such I don't want to have to send libraries along with it. itcl and other packages have a configure file that doesn't conditionalize USE_TCL_STUBS on --enable-shared, and in fact, various files just set it. Every time I update to a new Tcl version, I have to edit these out. Is there some reason (1) USE_TCL_STUBS can't be controlled by configure, and (2) have it be dependent on whether or not you are building a static library?

I was under the impression that with careful choice of options, using Stubs is Mostly Harmless even when linking statically. Tcl_InitStubs will lay a stubs table into the interp, and indirecting through the stubs table will work. The strange bit in the cited bug is that the code in question is calling TclOO_InitStubs without calling Tcl_InitStubs first (and TclOO_InitStubs won't call Tcl_InitStubs for you). But I could be misremembering, because it's been a while since I built fully static extensions.

Donal?