From: SourceForge.net <no...@so...> - 2003-07-03 22:30:52
|
Bugs item #765642, was opened at 2003-07-03 18:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=765642&group_id=12997 Category: 74. Application Embedding Group: 8.4.3 Status: Open Resolution: None Priority: 5 Submitted By: Don Porter (dgp) Assigned to: Don Porter (dgp) Summary: [load] Tk needs Tcl's --prefix Initial Comment: During a [load <Tk>], the Tk_Init() routine runs. In turn, it tries to eval the [tcl_findLibrary] command to find the installed tk.tcl file. If Tk was installed with TK_PREFIX the same as Tcl's TCL_PREFIX, then this will succeed. However, if Tk is installed somewhere else, and a Tcl interpreter tries to [load] it, there will be an error as Tk is unable to find the tk.tcl file. This means that Tk will not work correctly since it did not get initialized. There are a number of partial solutions possible. Tk's configure/build/install could be constrained to force TK_PREFIX to be the same as TCL_PREFIX. However, that just means the Tk will be [load]able in the Tcl installation it was configured against. The bug will remain when trying to [load] the same Tk shared library in a different Tcl installation. As requested in Tcl Feature Request 695441, [tcl_findLibrary] could be extended to also search directories on the auto_path. This would workaround this bug in the most common case where the [load] is wrapped inside the mechanics of [package require], and the search for require-able packages is done using [tclPkgUnknown] -- the default [package unknown] handler -- which is influenced by the value of ::auto_path. This will not fix the bug for direct [load]s though. Ultimately, the problem is that Tk_Init() needs a better tool/strategy for finding its script library than [tcl_findLibrary] is capable of providing. Since the Tcl world now includes virtual file systems, the ultimate solution may require embedding Tk's script library into the binary library itself as an internal file system so that this problem of finding and joining two separately installed pieces of Tk just goes away. Short of that, a revised installation strategy that installs the Tk script library under TK_EXEC_PREFIX in the same directory as Tk's pkgIndex.tcl file would also be a solution. There would be no need for a [tcl_findLibrary] call. The pkgIndex.tcl file would just arrange for source [file join $dir tk.tcl] to be part of Tk's package loading script. The cost of that solution is that on multi-architecture installations, each architecture gets its own copy of the Tk script library installed -- costing some disk space and costing some maintenance effort for those installations that make customizations to the script library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=765642&group_id=12997 |