Hi, all.
load right after tclsh is started(libmy.so is in current directory):
% load libmy.so
%
load after package require:
% package require test
can't find package test
% load libmy.so
couldn't load file "libmy.so": libmy.so: cannot open shared object file: No such file or directory
% load ./libmy.so
%
Why this is happen?
Hi, all.Check your current working directory (via [pwd]) at each stage; it may be that a package is changing it?
load right after tclsh is started(libmy.so is in current directory):
% load libmy.so
%
load after package require:
% package require test
can't find package test
% load libmy.so
couldn't load file "libmy.so": libmy.so: cannot open shared object file: No such file or directory
% load ./libmy.so
%
Why this is happen?
Check your current working directory (via [pwd]) at each stage; it may be that a package is changing it?
четверг, 14 октября 2021 г. в 20:53:38 UTC+3, conor.w...@gmail.com:
comrade -- a basic kestion...
dot is not in your LD_LIBRARY_PATH
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
This helps, but why loading works without manipulation with
LD_LIBRARY_PATH before package require command?
comrade -- a basic kestion...
dot is not in your LD_LIBRARY_PATH
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
Hi, all.
load right after tclsh is started(libmy.so is in current directory):
% load libmy.so
%
load after package require:
% package require test
can't find package test
% load libmy.so
couldn't load file "libmy.so": libmy.so: cannot open shared object file: No such file or directory
% load ./libmy.so
%
Why this is happen?
If you don't like the pckIndex mechanism, you may load it in the
following way from a TCL script in the same folder:
source [file join [file dirname [info script]] libmy.so]
IMU:
loading a lib from inside the interpreter does not look at LD_LIBRARY_PATH.
man n load ( or Windows equivalent. M$ seems to use some heuristics ..)
semi OT:
there is a search path defined for the [package require ... ] mechanism.
Never ever put "." in LD_LIBRARY_PATH, this opens up all kinds of
security and other problems.
As others have said, use the full path name for loading. Also, on
Linux, the .so needs to have proper execute permissions, but I think
you've checked that.
* "Oleg O. Nemanov" <oleg.o....@gmail.com>
| No-no. I like pkgIndex mechanism. I only noted an inconsistency
| in load behaviour before and after package require call.
I would suggest to recompile TCL with debugging information and
trace the calls to TclpDlopen() (unix/tclLoadDl.c) in a debugger.
That way you could check which pathnames are tried in each situation.
I can't see any obvious reason in the code for the behaviour you
describe...
пятница, 15 октября 2021 г. в 13:24:02 UTC+3, Ralf Fassel:
* "Oleg O. Nemanov" <oleg.o....@gmail.com>Hm. It's funny, but in 8.6.11 version of tcl i can't reproduce this. Before i
| No-no. I like pkgIndex mechanism. I only noted an inconsistency
| in load behaviour before and after package require call.
I would suggest to recompile TCL with debugging information and
trace the calls to TclpDlopen() (unix/tclLoadDl.c) in a debugger.
That way you could check which pathnames are tried in each situation.
I can't see any obvious reason in the code for the behaviour you describe...
tried 8.6.9.
Sorry. The wrong info :-). In 8.6.11 the same stranges.
On 15/10/2021 13:25, Oleg O. Nemanov wrote:
Sorry. The wrong info :-). In 8.6.11 the same stranges.
There must be some misbehaving package on your system. Executing
[package require test] causes all pkgIndex.tcl files found under the directories in $auto_path to be executed. These files are not supposed
to have any side-effects, other than updating the list of available
packages via [package provide] commands. But apparently one of the files does something more.
You can investigate by running [package names] before and after you do [package require test]. For each of the packages that newly appear, run [package versions <pkg>]. Then for each of the available versions of a suspected package, find the pkgIndex.tcl file and examine it.
You can narrow down the culprit by removing directories from $auto_path before doing the [package require test]. If that solves the problem, the rogue package is below one of the directories you removed.
...[CUT]...Done:
I.e. load behaviour is changed before any statements in pkgIndex.tcl.
% glob -nocomplain foo
% load libfswatch2.0.1.so
couldn't load file "libfswatch2.0.1.so": libfswatch2.0.1.so: cannot open shared object file: No such file or directory
The same happens with [pwd] and [cd]. It seems to me those commands initialize some filesystem access, after which [load] no longer looks in
the current directory.
This is curious. But since it already never works in a script, I don't
think it is really anything to worry about.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 25:52:15 |
Calls: | 6,448 |
Files: | 12,050 |
Messages: | 5,254,342 |