1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • Re: Where to put dll's in starkits

    From Robert Heller@21:1/5 to [email protected] on Thu Jun 19 17:53:35 2025
    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?

    At Thu, 19 Jun 2025 13:36:35 -0400 saito <[email protected]> wrote:


    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?







    --
    Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
    Deepwoods Software -- Custom Software Services
    http://www.deepsoft.com/ -- Linux Administration Services
    [email protected] -- Webhosting Services

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Heller@21:1/5 to [email protected] on Thu Jun 19 18:46:54 2025
    At Thu, 19 Jun 2025 14:29:28 -0400 saito <[email protected]> wrote:


    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.)





    --
    Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
    Deepwoods Software -- Custom Software Services
    http://www.deepsoft.com/ -- Linux Administration Services
    [email protected] -- Webhosting Services

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ted Nolan @21:1/5 to [email protected] on Thu Jun 19 19:25:28 2025
    In article <1031mad$1vhb$[email protected]>, saito <[email protected]> wrote: >On 6/19/2025 2:46 PM, Robert Heller wrote:


    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.

    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".
    --
    columbiaclosings.com
    What's not in Columbia anymore..

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Obermeier@21:1/5 to All on Thu Jun 19 21:39:36 2025
    Am 19.06.2025 um 20:29 schrieb saito:
    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.

    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.



    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.

    For Img or tksvg you do not need any external DLL's.
    Img contains the needed PNG, JPEG and TIFF libraries already.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Heller@21:1/5 to [email protected] on Fri Jun 20 00:08:23 2025
    Starkits re-define load to take care of shared libraries (.dlls, .so, etc.)
    and will copy them to someplace like /tmp and then calling the original load command to load them via libdl (or the MS-Windows equivalent). That is,
    shared libraries management is "transparent" and there is no need for special code in the application itself -- eg one just uses a 'package require ' and it just works properly.

    At Thu, 19 Jun 2025 17:50:37 -0400 saito <[email protected]> wrote:


    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.



    --
    Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
    Deepwoods Software -- Custom Software Services
    http://www.deepsoft.com/ -- Linux Administration Services
    [email protected] -- Webhosting Services

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ralf Fassel@21:1/5 to All on Fri Jun 20 10:19:02 2025
    * Robert Heller <[email protected]>
    | 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).

    Check
    https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
    for the standard search path for DLLs on Windows, paragraph
    Standard search order for unpackaged apps

    The fact that there are DLLs in bin/ is due to topic 7, search "the
    folder from which the app loaded".

    BUT: this applies *only* to DLLs which the app requires to run at all
    (run-time linker). Anything you directly 'load' via TCLs [load] command
    can be located anywhere in the file system (if thoses DLLs indirectly
    require other DLLs, the search path as above kicks in again, and here
    I'm not certain whether point 7 also holds for "the folder where the DLL
    was loaded from").

    HTH
    R'

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)