When creating a starkit, there is a specific hierarchy to follow with
the vfs folder. For example, you put your packages in "lib".
However, some packages have dll components that normally reside in the
bin folder of your Tcl/Tk installation. How do you handle these dll
files? Where do they go? Is there a way to ask the starkit to check a certain place for any dll's it may need?
Needing to put dlls in "bin" under MS-Windows is specific to MS-Windows, when the dlls are searched for and loaded my MS-Windows itself and I think only applied to Tcl itself being in a dll (shared library). A starkit includes a staticly build Tcl interpreter. Tk is still a shared library (dll), but this is loaded by Tcl using the load command.
There should not be any reason to to have a "bin" folder. I think all dlls should go somewhere under lib.
Do you have a specific package or set of dlls that are handled differently?
On 6/19/2025 1:53 PM, Robert Heller wrote:
Needing to put dlls in "bin" under MS-Windows is specific to MS-Windows, when
the dlls are searched for and loaded my MS-Windows itself and I think only applied to Tcl itself being in a dll (shared library). A starkit includes a
staticly build Tcl interpreter. Tk is still a shared library (dll), but this
is loaded by Tcl using the load command.
There should not be any reason to to have a "bin" folder. I think all dlls should go somewhere under lib.
I wasn't suggesting that it should. The "bin" refers to "bin" under the
main, full Tcl/Tk installation. There I see a bunch of dll's some of
whose names suggest they may be related to image processing.
Do you have a specific package or set of dlls that are handled differently?
I was trying to create a starkit with image related packages. I can't
get svg support for example. I have included all packages related to img including tksvg. They are present in the vfs lib folder. jpeg is also problematic. It seems like they need some dll's beyond what is included
in their "package" folders.
OK, this is related to the Img package. It expcts some "system libraries" to be installed. I guess someplace like C:\System32 (or whatever MS-Windows uses for what Linux would call /usr/lib. I am not sure what the MS-Windows libraries it needs are, but the Linux dependencies under Linux (Debian, arm64)
for libtk-img 1.4.14 include: libjpeg62-turbo, libpng16-16, and libtiff6. I believe these DLLs are readily available.
I don't really know what the proper way to deal with this under MS-Windows. My only real thought would be to re-build tk-img staticly linked to these graphics libraries. (Under Linux these sorts of libraries are often pulled in
by various other graphics programs.)
OK, this is related to the Img package. It expcts some "system libraries" to >> be installed. I guess someplace like C:\System32 (or whatever MS-Windows uses
for what Linux would call /usr/lib. I am not sure what the MS-Windows
libraries it needs are, but the Linux dependencies under Linux (Debian, arm64)
for libtk-img 1.4.14 include: libjpeg62-turbo, libpng16-16, and libtiff6. I >> believe these DLLs are readily available.
I don't really know what the proper way to deal with this under MS-Windows. >> My only real thought would be to re-build tk-img staticly linked to these
graphics libraries. (Under Linux these sorts of libraries are often pulled in
by various other graphics programs.)
That's a good idea.
On 6/19/2025 1:53 PM, Robert Heller wrote:
Needing to put dlls in "bin" under MS-Windows is specific to MS-Windows, when
the dlls are searched for and loaded my MS-Windows itself and I think only >> applied to Tcl itself being in a dll (shared library). A starkit includes a
staticly build Tcl interpreter. Tk is still a shared library (dll), but this
is loaded by Tcl using the load command.
There should not be any reason to to have a "bin" folder. I think all dlls >> should go somewhere under lib.
I wasn't suggesting that it should. The "bin" refers to "bin" under the main, full Tcl/Tk installation. There I see a bunch of dll's some of whose names suggest they may be related to image processing.
Do you have a specific package or set of dlls that are handled differently? >>
I was trying to create a starkit with image related packages. I can't get svg support for example. I have included all packages related to img including tksvg. They are present in the vfs lib folder. jpeg is also problematic. It seems like they need some dll's beyond what is included in their "package" folders.
It seems you are using some kind of Tcl BI distribution, ex. BAWT.
A lot of DLL's are in the bin directory, which are needed by several packages.
For Img or tksvg you do not need any external DLL's.
Img contains the needed PNG, JPEG and TIFF libraries already.
It's been a while since I've done anything with Windows, but I seem
to recall that when I was trying to deal with a DLL bundled in a
"freewrap" application, that my startup code had to extract the DLL
to the "real" filesystem and either make sure it went to something
searched in the Windows "PATH" ("Path") or add that directory to the
Windows "PATH".
On 6/19/2025 3:25 PM, Ted Nolan <tednolan> wrote:
It's been a while since I've done anything with Windows, but I seem
to recall that when I was trying to deal with a DLL bundled in a
"freewrap" application, that my startup code had to extract the DLL
to the "real" filesystem and either make sure it went to something
searched in the Windows "PATH" ("Path") or add that directory to the Windows "PATH".
I believe this is true. Earlier I had set tcl's own auto_path which
sometimes helps.
At this point I am convinced it is a silly mistake on my part.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 163:56:45 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
9,208 files (2,741M bytes) |
| Messages: | 2,411,516 |