| Ticket UUID: | 976438 | |||
| Title: | Cannot find "init.tcl" on Unix... | |||
| Type: | Bug | Version: | obsolete: 8.5a2 | |
| Submitter: | mistachkin | Created on: | 2004-06-20 23:40:03 | |
| Subsystem: | 38. Init - Library - Autoload | Assigned To: | dgp | |
| Priority: | 9 Immediate | Severity: | ||
| Status: | Closed | Last Modified: | 2004-11-23 14:56:43 | |
| Resolution: | Fixed | Closed By: | dgp | |
| Closed on: | 2004-11-23 07:56:43 | |||
| Description: |
The Unix initialization code should semantically match
the Windows code and be able to search for "init.tcl"
using at least the relative paths "../lib/" and "../library/".
ERROR:
./tclsh
application-specific initialization failed: Can't find a
usable init.tcl in the following directories:
/usr/local/lib/tcl8.5
This probably means that Tcl wasn't installed properly.
| |||
| User Comments: |
dgp added on 2004-11-23 14:56:43:
Logged In: YES user_id=80530 Actually, those tests pass just fine so long as the toplevel name of the Tcl source directory is correct. Current correct name should be tcl8.5a2 This is the name produced by unpacking the official tarballs. Failure to cvs checkout into a directory with that name may be considered pilot error. dgp added on 2004-11-23 11:49:38: Logged In: YES user_id=80530 ok, that patch helped a lot, but still leaves tests unixInit-2.2-4 failing in a macosx build. The TCL_LIBRARY value supplied during `make test` is required to successfully initialize, so the tests that set TCL_LIBRARY to something else end up failing. dgp added on 2004-11-23 04:24:40: Logged In: YES user_id=80530 patch committed for 8.5a2. dgp added on 2004-11-23 02:52:20: File Added - 109730: 976438.patch Logged In: YES user_id=80530 This patch restores directories to the search path for init.tcl, but not to the search path for encodings. This should restore the robustness of Tcl startup in testing environments, but should not bring back the mega-surplus filesystem stat-ing that bogged down start up. Testing on non-unix platforms recommended. dgp added on 2004-07-01 22:40:12: Logged In: YES user_id=80530 This issue may cause trouble with tclbench as well. When tclbench wants to run several tclsh programs from their build directories, it will not be using the `make shell` convention, so the reduced init.tcl/encoding search paths may cause failure. dgp added on 2004-06-21 12:08:41: Logged In: YES user_id=80530 The change you see compared with Tcl 8.4 is the result of some work in progress trying to simplify the numerous search paths that lead Tcl to "wander all over the filesystem: at startup. Some recent testing showed hundreds to thousands of "stat" calls, mostly on non-existent files, just to initialize the Tcl library. To run the tclsh program you just built from within the build directory, and without installing it, the recommended technique is $ make shell rather than $ ./tclsh Use that as a workaround, while we continue work on reforming the startup sequence, and consider this bug report further. | |||
Attachments:
- 976438.patch [download] added by dgp on 2004-11-23 02:52:20. [details]