[Tcl-bugs] [ tcl-Bugs-533221 ] Problems with binary packages on NT 4.0

[<no...@so...>]

Bugs item #533221, was opened at 2002-03-21 09:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=533221&group_id=10894

Category: 37. Package Manager
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Nelson (chris_nelson)
Assigned to: Don Porter (dgp)
Summary: Problems with binary packages on NT 4.0

Initial Comment:
For RFE 4097, sourceforge bug 219042 (pkg_mkIndex unnecessarily creates command list for 
direct lo), changes were made to pkg_mkIndex that appear to have undesireable side effects.  
Here's the note from my colleague:

------------------------
The first issue is a change in some default behavior which I believe should
be questioned.  The second appears to be a real bug.

    First, the pkg_mkIndex default behavior changed from setting up
lazy loading to doing direct loading.  I found the bug (4097 RFE) which
led to the change in pkg_mkIndex.  However, it was only a request for
an optimization to pkg_mkIndex when the -direct switch was used.  The
change to the default behavior appears to have slipped in at that point.
I am concerned that this represents a change in "philosophy" with regard
to "package require".  I used to consider them to be essentially "free"
and scatter them about with relative abandon.  Now, I have to be aware
that, by default, the first time a package is required the flow will
stop while the package is loaded.

    However, this is but a trifle.  The real issue is this.  We have
some DLLs which have both Tcl and non-Tcl entry points.  So, we link our
binaries against them, but also do "package require" calls which will
ultimately dynamically load the same DLLs.  Our pkg_mkIndex calls, and
thus the resulting pkgIndex.tcl files, have been carefully crafted to
insure that the DLL that is loaded by Tcl (using a relative path) is
referencing the same file as the one the OS will load when the .exe
originally bootstraps.

    Well, when the package is done loading, we end up with two copies of
the DLL in memory, but ONLY ON NT 4.0!  ... The doubly-loaded DLL is, I thought,
not supposed to be possible.

    When we go back to our Tcl-8.2-based product, the doubly-loaded
DLL problem does not occur, regardless of direct or lazy package loading.
The win/tclWinLoad.c file appears only to have changed with regard to
improved error handling from 8.2 to 8.4.

------------------------
We initially thought that reverting to lazy loading with Tcl 8.4 solved the problem but have gotten 
inconsistent results in further testing.

This is in 8.4a3, a "Group" which doesn't appear to exist.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=533221&group_id=10894