[Starkit]s and their interaction with binary [extension]s are a bit of magic, but the simpler cases are quite easy to do and understand.1

'''Simple case:''' Single platform, [stubs] enabled binary extensions with no external dependencies.

This is the easy case for packages like [tdom] or [tktable], which do not depend on external .so or .dlls to work.
Put the .so/.dll in the virtual filesystem and write/use a [pkgIndex.tcl] file that loads it when a package require is done.
For many packages, copying the package subdir of /lib into the $::starkit::topdir/lib dir of the vfs is enough to make it work.  

Example:
 # binary.tcl
 package require Tk
 package require Tktable
 puts "Loaded ok"

Wrap it and unwrap to create directory:
 sdx.kit qwrap binary.tcl
 sdx.kit unwrap binary.kit
 
Copy the binary Tktable libs in:
 cp /path/to/Tktable2.8 binary.vfs/lib

Rewrap the code:
 sdx.kit wrap binary

'''Medium case:''' Multiple platform, stubs enabled binary extension with no external dependencies.

'''Harder case:''' Single platform, [stubs] enabled binary extension with external dependencies.


'''Impossible case:''' Non stubs enabled, shared library binary extension.

[Zarutian] 31. july 2004: How portable are those extensions?

Depends. Many are just ANSI C, others are complex and interact with the platform.

----
See also [sdx].

----
[Category Deployment] | [Category Tclkit]