Starkits use some fancy tricks in order to be able to load libraries that are stored in the virtual filesystem bundled into the starkit itself. On Unix, you can direct the OS library loader to load a library from an arbitrary block of data, but on Windows, you can only load libraries from actual files on disk.
In order to accommodate that limitation, Windows starkits first copy the library out of the virtual filesystem to the real filesystem as a temp file. That's where your temp file names are coming from.
Now, all of that works fine as long as the libraries in your starkit do not themselves have dependencies on other libraries in your starkit. In your case, your libmysqltcl.dll probably depends on libmySQL.dll. At the time of loading, both of those have been copied to the real filesystem, but with temp file names, so the loader is not able to find libmySQL.dll.
You have a couple choices for working around this:
Eliminate these second-level dependencies from your libraries. In this case, that means rebuilding libmysqltcl.dll with static linkage to the stuff in libmySQL.dll, rather than dynamically linking it against the dll.
Before the package require in your startup script, explicitly copy the second-level dependencies out of your starkit to a location on the real filesystem, then update the PATH environment variable to include that directory.
Option #2 would look something like this:
set dirname [file dirname [info script]]
set tmpdir [file join $env(TEMP) __myapp__]
file mkdir $tmpdir
foreach dll {libmySQL.dll} {
if { ![file exists [file join $tmpdir $dll]] } {
file copy -force [file join $dirname bin $dll] $tmpdir
}
}
set ::env(PATH) "$tmpdir;$env(PATH)"
Then you should be able to do your package require as expected.
It's a bit clunky for sure, but the blame lies pretty squarely on Windows for not allowing you to load libary code from memory rather than from a file.