However, it turns out that it does this each and every time you run it.
This seems excessive. It adds to the startup time, it wastes space and
it creates lots of duplicate folders.
I wonder if tclkit could be enhanced in a simple way that keeps the
benefits and avoids the negatives: use the wrapped kit name, or some
hash of it, and use that as the folder name where to extract the dll's.
If it exists, skip the file extract/copy/save operation. Otherwise, it
means it is the first time the app is running, and it can extract the files.
I recently built a custom tclkit and wrapped it. I noticed that when it runs, it extracts its dll's and other stuff. This is fine.
However, it turns out that it does this each and every time you run it.
This seems excessive. It adds to the startup time, it wastes space and
it creates lots of duplicate folders.
I wonder if tclkit could be enhanced in a simple way that keeps the
benefits and avoids the negatives: use the wrapped kit name, or some
hash of it, and use that as the folder name where to extract the dll's.
If it exists, skip the file extract/copy/save operation. Otherwise, it
means it is the first time the app is running, and it can extract the files.
That seems like it would leave you open to a number of issues. Security obviously, but maybe you have a shared filesystem and last time you
ran the ubuntu version of the kit and this time you ran the redhat
one and their dlls are complied against different glibc versions or whatever.
There really isn't any sensible way to do this. There really isn't to be certain that the extracted dlls/sos are really the correct ones.
The startup cost is probably small. I don't know about MS-Windows specificly, but I believe under Linux, the extracted so files are marked for deletion on program exit. I think under Linux, the so files are extracted to /tmp, which on most modern Linuxes is a RAMDISK (eg it is gone on reboot), I don't know why there would be duplicate directories, unless it is another MS-Windows "weirdness".
On 8/8/2025 12:43 PM, Ted Nolan <tednolan> wrote:(Same user name on different systems is very common in the Linux / UNIX
That seems like it would leave you open to a number of issues. Security obviously, but maybe you have a shared filesystem and last time you
ran the ubuntu version of the kit and this time you ran the redhat
one and their dlls are complied against different glibc versions or whatever.
You can compare dll file info one by one, including their checksums.
The shared file system scenario seems interesting and limited to Linux.
Is it common? In any case, it is easy to address it: just include user
name somehow in the folder name. I doubt the same user would be using multiple Linux versions at the same time.
I am not sure file sharing is really an issue anyway. Under Linux (and probably MacOSX) there is almost never going to be a reason to "share" /tmp...
I recently built a custom tclkit and wrapped it. I noticed that when it runs, it extracts its dll's and other stuff. This is fine.
However, it turns out that it does this each and every time you run it.
This seems excessive. It adds to the startup time, it wastes space and
it creates lots of duplicate folders.
I wonder if tclkit could be enhanced in a simple way that keeps the
benefits and avoids the negatives: use the wrapped kit name, or some
hash of it, and use that as the folder name where to extract the dll's.
If it exists, skip the file extract/copy/save operation. Otherwise, it
means it is the first time the app is running, and it can extract the
files.
this is an open issue since at least 20 years.
This is starkit technology by JC Wipfler.
We had last year a heavy discussion on this point, if dlls may be memory loaded.
A side aspect of it is this TIP:
On the practical side, you may follow the solution I use and presented
here:
https://wiki.tcl-lang.org/page/Single+file+applications+in+Tcl+9
I also used it for starkits.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 170:41:12 |
| Calls: | 13,692 |
| Files: | 186,936 |
| D/L today: |
90 files (19,324K bytes) |
| Messages: | 2,411,676 |