Tk Source Code

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.

Logged In: YES 
user_id=79902
Originator: NO

One possibility is to put all Tcl-related packages (including Tk) beneath, say, /usr/lib/tcl and /usr/share/tcl. That would at least allow things to be set so that loads of useless directories aren't searched, and Tcl packages are typically agnostic to their install location.

Logged In: YES 
user_id=244388
Originator: NO

Fedora (and possibly RHEL) would like to run Tcl with a restricted auto_path that does not include /usr/lib and /usr/share in order to optimize the startup time of the Tcl interpreter.  Unfortunatley, this causes wish to run tcl_findLibrary and fail to find tk.tcl.

It would be nice if this bug could be fixed in the Tk's next alpha/beta release so that it could make it into the next Fedora release due in a few months.

See Tcl bug #1655677 for more details.

Logged In: YES 
user_id=80530


If Tk is updated to call 
Tcl_RegisterConfig, we
could close this, I think.

Possible for Tk 8.5a2 ?

Logged In: YES 
user_id=80530

[tcl_findLibrary]'s search path has
been expanded to include the $::auto_path
which should solve this for the common
[package require Tk] situation.

[tcl_findLibrary] also checks the
scriptdir,runtime value registered
by a package with Tcl_RegisterConfig.
See TIP 205 for a proposal to have Tk
make use of this new config registration
interface.

Logged In: YES 
user_id=80530


For 8.4.5, changed Tk's configure
to default TK_PREFIX to the
value of TCL_PREFIX, and to
print a warning if the user selects
a configuration where they are
not the same.

Leaving open for a more flexible fix.

Logged In: YES 
user_id=80530


Another solution opens up in Tcl 8.5.
The C API provided by TIP 59 could
be used to embed in the Tk shared
library the configured directory for
storing Tk's script library.  Then the
[tk::pkgconfig] command could
retrieve that value and use it to
initialize tk_library.

More generally, [tcl_findLibrary foo ...] could
be extended to call the foo::pkgconfig
command and retrieve the value of
a conventional key ("scriptdir,runtime" ?)
and add it to the search path.

Logged In: YES 
user_id=80530

er, a better way to accomplish the last approach
is to add

    set ::tk_library $dir

to Tk's package loading script rather than
directly [source] tk.tcl