create .dll in windows for tcl/tk starkit

Question

I have a .so(for example abc.so) file created using swig in unix which i am abe to load in the tcl program using 'load abc.so'. I plan to run the tcl program in windows, therefore need to create a corresponding abc.dll file which can be loaded similarly. Kindy guide the procedure to achieve this. Thanks!

Answer 1

If you're preparing a Tcl extension in a DLL to go into a starkit, the main thing you need to do is to make sure that the extension is built in stubs enabled mode . There are several parts to this:

1. You need to define the C symbol USE_TCL_STUBS when compiling the code. If you're also using the Tk API — less common, but might be true given your description — you also need to specify USE_TK_STUBS . These symbols are often best specified using compiler options, and specifying them causes Tcl to rewrite virtually all API function calls into stubbed calls.

2. You need to call Tcl_InitStubs as the first step of your extension's init function, and if you're using the Tk API then you call Tk_InitStubs as the second step. These two calls initialise the binding of the stubbed API calls so that they point to something real. Note that these API calls are also safe to use when your extension is not built in stubbed mode.

3. You need to link against the Tcl (and possibly the Tk) stubs library, which is a static library. This provides the implementation of the stubbed calls (so that they call into the implementations inside the host Tcl interpreter) and the initialisation function(s).

This is all necessary because in a starkit (just as in many other wrapping technologies) the Tcl API is not implemented by the usual Tcl DLL. Instead, the Tcl code is statically linked into an executable and the name of that executable isn't safely knowable at extension build time; using stubbed calls avoids binding the literal name of the library into your code, and that's the cause of what goes wrong when you don't use stubs.

---

^{NB: Only Tcl/Tk extensions can be stub-enabled (unless the code to do the work is duplicated and reused) since the binding mechanism depends on having a Tcl interpreter context to convey the API descriptor structure references to the right places. Non-extension libraries require other, significantly more advanced techniques to work from a packaged environment (and the simplest way of dealing with them is often to bind them statically to a DLL that contains a Tcl extension, virtually always the DLL that contains the relevant Tcl binding layer for making an extension that uses the functionality).}