Question

I need a simple C program which creates tcl interpreter, initializes tcl and tk and then loads a given tcl/tk script. I want to use tcl and tk stubs (to ensure that the program will run on the computer with different version of tcl/tk). I will use this program instead of running wish (because I have portability problems).

#include <stdio.h>
#include <stdlib.h>
#include <tcl.h>
#include <tk.h>

int AppInit(Tcl_Interp *interp) {
  if(Tcl_Init(interp) == TCL_ERROR) return TCL_ERROR;
  if(Tk_Init(interp) == TCL_ERROR) return TCL_ERROR;
  Tcl_EvalFile(interp,"myscript.tcl");
  return TCL_OK;
}

int main(int argc, char *argv[]) {
  Tk_Main(argc, argv, AppInit);
  return 0;
}

I tried to compile (on GNU/Linux) with the following command. Program compiles without errors, but then stop with segmentation fault.

gcc -I/usr/include/tcl8.5 -DUSE_TCL_STUBS -DUSE_TK_STUBS -o main.exe ../main.c /usr/lib/libtclstub.a /usr/lib/libtkstub.a

Answer 1

tl;dr

When compiling a program with a main, you shouldn’t use stubs. Instead, build without the USE_TCL_STUBS and USE_TK_STUBS defines and link against libtcl.so and libtk.so (well, with whatever version number’s been attached to them). Because of peculiarities in the Unix linker, you should put the Tk library before the Tcl library (and you might also need to manually link against other libs too, such as the X library; linking is occasionally a bit of a black art).

Background Explanation

The stubs mechanism is intended to allow a Tcl extension library to use Tcl’s (and Tk’s) C API without having to be linked against the Tcl library itself. This means that the library is agnostic to what exact version of Tcl is present in the process loading it, and instead just depends on a particular version of the Tcl API (Tcl’s pretty good at managing long term API and ABI compatibility). However, this all depends on the library initialization function getting called with a very particular kind of pointer which allows all the other API functions to be looked up. (Once Tcl’s been bootstrapped this way, it becomes much easier to find all the other APIs.) When creating an application like you’re doing, you run into a problem in that there’s no existing bootstrapped Tcl library instance for your code to link against; it has to be linked directly (and in fact both Tcl_Main and Tk_Main are non-stubbed functions for this exact reason).

Those of you reading along at home might think that this is Tcl repeating a lot of what the system dynamic linker does. You’d be right. However the system dynamic linker has a number of ways it can do things that don’t work quite right (e.g., it can get very confused when there are multiple versions of a library about) and it varies subtly in its capabilities between platforms. Tcl uses its own mechanism because that makes it work precisely right (for Tcl) everywhere, giving us much better control over long-term ABI compatibility.

There is an exception to the above rule about stubs, and that is tclkit, which is a full Tcl and Tk runtime (plus a small NoSQL DB) in a single file. The bootstrapping code for tclkit is horrendously complex though; you don’t want to have to deal with that sort of thing you don’t have to! If you want a single-file Tcl runtime, you use tclkit (or one of the few other systems that do pretty much equivalent things).