activetcl install links to old init.tcl
qrs...@gmail.com
I'm installing ActiveTcl8.4.19.1, and 8.5.2.0 and usually this works
for me but in this particular case, I am having some problems -
specifically, the install is linking to an already existing 8.4.7 tcl
that is part of the standard Centos release instead of the
tclsh8.4.19.1 that I am trying to install. I don't get the problem
with the ix86 install.
Any suggestions on what I can do to diagnose the problem?
I have followed these steps:
From within the bin directory of the unzipped active state 8.4.19.1
x86_64 tar ball:
./install.sh (and I pick the-install-directory)
cd to the-install-directory/bin
./teacup update-self (same problem when I don't update-self)
./install --force --at ../lib/teapot ActiveState::ActiveTcl -is
profile
./tclsh8.4
% package require textutil
can't find package textutil
% info library
/usr/share/tcl8.4 -> this is wrong
% set tcl_version
8.4
% info patchlevel
8.4.7 -> this is wrong
% set auto_path
/usr/share/tcl8.4 /usr/share /usr/lib64 /usr/lib /tools/ecad/local/
x86_64/lib
% set tcl_pkgPath
/usr/lib64 /usr/share
% set tcl_libPath
/tools/ecad/local/x86_64/lib/tcl8.4 /tools/ecad/local/lib/tcl8.4 /
tools/ecad/local/x86_64/library /tools/ecad/local/library /tools/ecad/
local/tcl8.4.7/library /tools/ecad/tcl8.4.7/library /usr/share/tcl8.4
Running it directly:
> /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin/tclsh8.4
% set argv0
/tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin/tclsh8.4
% info library
/usr/share/tcl8.4
env | grep -i tcl - gives nothing
LD_LIBRARY_PATH is unset
Thanks in advance for any ideas.
Peter
Andreas Kupries
> Folks,
>
> I'm installing ActiveTcl8.4.19.1, and 8.5.2.0 and usually this works
> for me but in this particular case, I am having some problems -
> specifically, the install is linking to an already existing 8.4.7 tcl
> that is part of the standard Centos release instead of the
> tclsh8.4.19.1 that I am trying to install. I don't get the problem
> with the ix86 install.
Hm. Are we not talking about an ix86 install here ?
> Any suggestions on what I can do to diagnose the problem?
>
> I have followed these steps:
>
> From within the bin directory of the unzipped active state 8.4.19.1
> x86_64 tar ball:
Ah, a Linux 64bit ActiveTcl.
> ./install.sh (and I pick the-install-directory)
Side note: The install.sh is not in a bin/ sub-directory, but in the
toplevel directory of the tarball.
> cd to the-install-directory/bin
> ./tclsh8.4
> % package require textutil
> can't find package textutil
> % info library
> /usr/share/tcl8.4 -> this is wrong
What does 'ldd' tell you about shared library resolution ? I.e.
% ldd ./tclsh8.4
will list the shared libraries the tclsh is linked with, and how the
dynamic linker will resolve them to actual libraries in the system.
My guess is that we will see the libtcl.so resolved to the system
library, and from there we get all the wrong data, i.e wrong version,
paths, etc.
> % set tcl_libPath
> /tools/ecad/local/x86_64/lib/tcl8.4 /tools/ecad/local/lib/tcl8.4 /
> tools/ecad/local/x86_64/library /tools/ecad/local/library /tools/ecad/
> local/tcl8.4.7/library /tools/ecad/tcl8.4.7/library /usr/share/tcl8.4
This seems to show some of your install paths, assuming that
tools/ecad/... is the-install-directory. You are not saying.
> Running it directly:
>> /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin/tclsh8.4
Is that the installed tclsh, just with an absolute path ?
Or the uninstalled tclsh from the tarball ?
> % set argv0
> /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin/tclsh8.4
> % info library
> /usr/share/tcl8.4
Try the following commands on the installed tclsh, and the tclsh in
the tarball, before installation:
(1) % strings -a tclsh |grep @__
(2) % strings -a tclsh |grep part-of-your-installdir-path
The installed tclsh should return nothing for (1), and something for
(2), and the tclsh in the tarball the reverse, nothing for (2),
something for (1).
Context: I am checking of the binary patching performed during the
installation weas done.
--
So long,
Andreas Kupries <akup...@shaw.ca>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------
qrs...@gmail.com
> qrs0...@gmail.com writes:
> > Folks,
>
> > I'm installing ActiveTcl8.4.19.1, and 8.5.2.0 and usually this works
> > for me but in this particular case, I am having some problems -
> > specifically, the install is linking to an already existing 8.4.7 tcl
> > that is part of the standard Centos release instead of the
> > tclsh8.4.19.1 that I am trying to install. I don't get the problem
> > with the ix86 install.
>
> Hm. Are we not talking about an ix86 install here ?
>
> > Any suggestions on what I can do to diagnose the problem?
>
> > I have followed these steps:
>
> > x86_64 tar ball:
>
> Ah, a Linux 64bit ActiveTcl.
>
>
> Side note: The install.sh is not in a bin/ sub-directory, but in the
> toplevel directory of the tarball.
>
> > cd to the install directory: /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin
> > ./tclsh8.4
> > % package require textutil
> > can't find package textutil
> > % info library
> > /usr/share/tcl8.4 -> this is wrong
>
> What does 'ldd' tell you about shared library resolution ? I.e.
>
> % ldd ./tclsh8.4
> cd /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin
base-tcl-linux-x86_64* base-tk-linux-x86_64* page*
tclsh* teacup* wish*
base-tcl-linux-x86_64.so* dtplite* tcldocstrip*
tclsh8.4* tkcon* wish8.4*
/tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin {276}> ldd ./tclsh8.4
libtcl8.4.so => /usr/lib64/libtcl8.4.so (0x0000003e53700000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000002a9566c000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a9576f000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a958f5000)
/lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
That tcl files exists but is not part of the current ActiveTcl
install:
/usr/lib64 {298}> ls -lrt libtcl8.4.so
-rwxr-xr-x 1 root root 772096 Jul 25 2008 libtcl8.4.so*
>
> will list the shared libraries the tclsh is linked with, and how the
> dynamic linker will resolve them to actual libraries in the system.
>
> My guess is that we will see the libtcl.so resolved to the system
> library, and from there we get all the wrong data, i.e wrong version,
> paths, etc.
>
> > % set tcl_libPath
> > /tools/ecad/local/x86_64/lib/tcl8.4 /tools/ecad/local/lib/tcl8.4 /
> > tools/ecad/local/x86_64/library /tools/ecad/local/library /tools/ecad/
> > local/tcl8.4.7/library /tools/ecad/tcl8.4.7/library /usr/share/tcl8.4
>
> This seems to show some of your install paths, assuming that
> tools/ecad/... is the-install-directory. You are not saying.
The actual install directory is /tools/ecad/local/x86_64/
ActiveTcl8.4.19.1, is it supposed to be looking in all these
variations of the install dir? And the 8.4.7 must be wrong since
8.4.19.1 is what is being installed.
>
> > Running it directly:
> >> /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin/tclsh8.4
>
> Is that the installed tclsh, just with an absolute path ?
Yes
> Or the uninstalled tclsh from the tarball ?
No
>
> > % set argv0
> > /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin/tclsh8.4
> > % info library
> > /usr/share/tcl8.4
>
> Try the following commands on the installed tclsh, and the tclsh in
> the tarball, before installation:
>
> (1) % strings -a tclsh |grep @__
> (2) % strings -a tclsh |grep part-of-your-installdir-path
>
> The installed tclsh should return nothing for (1), and something for
> (2), and the tclsh in the tarball the reverse, nothing for (2),
> something for (1).
>
Installed tclsh8.4 (same result for tclsh):
/tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin {287}> strings -a ./
tclsh8.4 | grep @_
/tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin {288}> strings -a ./
tclsh8.4 | grep tools/ecad
/tools/ecad/local/x86_64/ActiveTcl8.4.19.1/lib
Tarball tclsh8.4 (same result for tclsh):
.../ActiveTcl8.4.19.1.286921-linux-x86_64/payload/bin> strings -a ./
tclsh8.4 | grep @_
@________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________@
.../ActiveTcl8.4.19.1.286921-linux-x86_64/payload/bin> strings -a ./
tclsh8.4 | grep tools/ecad
.../ActiveTcl8.4.19.1.286921-linux-x86_64/payload/bin>
> Context: I am checking of the binary patching performed during the
> installation weas done.
>
So the binary patching seems to be right yet when I load tclsh8.4 and
do info library I get this:
/tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin {295}> ./tclsh8.4
% info library
/usr/share/tcl8.4
How would it pick up that library which is the old install?
Thanks for your help.
Peter
> --
> So long,
> Andreas Kupries <akupr...@shaw.ca>
Andreas Kupries
>> > cd to the install directory: /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin
>> > ./tclsh8.4
>> > % package require textutil
>> > can't find package textutil
>> > % info library
>> > /usr/share/tcl8.4 -> this is wrong
>>
>> What does 'ldd' tell you about shared library resolution ? I.e.
>>
>> % ldd ./tclsh8.4
> /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin {276}> ldd ./tclsh8.4
> libtcl8.4.so => /usr/lib64/libtcl8.4.so (0x0000003e53700000)
Ok, this is the wrong resolution causing all the problems.
>> > % set tcl_libPath
>> > /tools/ecad/local/x86_64/lib/tcl8.4 /tools/ecad/local/lib/tcl8.4 /
>> > tools/ecad/local/x86_64/library /tools/ecad/local/library /tools/ecad/
>> > local/tcl8.4.7/library /tools/ecad/tcl8.4.7/library /usr/share/tcl8.4
>>
>> This seems to show some of your install paths, assuming that
>> tools/ecad/... is the-install-directory. You are not saying.
> The actual install directory is /tools/ecad/local/x86_64/
> ActiveTcl8.4.19.1, is it supposed to be looking in all these
> variations of the install dir? And the 8.4.7 must be wrong since
> 8.4.19.1 is what is being installed.
The 8.4.7 comes again from the bad libtcl we picked up. The others are
standard, as far as I can tell.
>> Try the following commands on the installed tclsh, and the tclsh in
>> the tarball, before installation:
>>
>> (1) % strings -a tclsh |grep @__
>> (2) % strings -a tclsh |grep part-of-your-installdir-path
>>
>> The installed tclsh should return nothing for (1), and something for
>> (2), and the tclsh in the tarball the reverse, nothing for (2),
>> something for (1).
> Installed tclsh8.4 (same result for tclsh):
> /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin {287}> strings -a ./
> tclsh8.4 | grep @_
> /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/bin {288}> strings -a ./
> tclsh8.4 | grep tools/ecad
> /tools/ecad/local/x86_64/ActiveTcl8.4.19.1/lib
Looks good.
> Tarball tclsh8.4 (same result for tclsh):
> .../ActiveTcl8.4.19.1.286921-linux-x86_64/payload/bin> strings -a ./
> tclsh8.4 | grep @_
> @________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________@
> .../ActiveTcl8.4.19.1.286921-linux-x86_64/payload/bin> strings -a ./
> tclsh8.4 | grep tools/ecad
And good again.
> .../ActiveTcl8.4.19.1.286921-linux-x86_64/payload/bin>
>
>> Context: I am checking of the binary patching performed during the
>> installation weas done.
>>
> So the binary patching seems to be right
Yes, it looks good.
> How would it pick up that library which is the old install?
That is the question. First suspect would be LD_LIBRARY_PATH, however
you said in your first post that this variable was not set, excluding
it from consideration.
Reading the ld.so manpage on my system it claims
The necessary shared libraries needed by the program are searched for in the following order
o Using the environment variable LD_LIBRARY_PATH ...
o From the cache file /etc/ld.so.cache which contains ...
o In the default path /usr/lib, and then /lib.
This doesn't list the rpath information, which is what we are patching
in the tclsh ... I.e. it may be that the ld cache mentioned above has
priority over the rpath information in the executable itself.
You might have to delete/rename the /usr/lib64/libtcl8.4.so
to get the dynamic linker to find the correct shared library.
I am not sure if we can override this, it might be a linux issue. You
might wish to ask about this on a CentOS newsgroup and/or mailing list
as well. And I would be interested in any answers too.
--
So long,
Andreas Kupries <akup...@shaw.ca>
qrs...@gmail.com
Thanks for your suggestions. I believe I can get it working without
playing with LD_LIBRARY_PATH using a
script to run tclsh rather than a soft link and by changing the tclsh
to use only DT_RPATH and not both
DT_RPATH and DT_RUNPATH. It picks the right library when invoked but I
don't know if there are any
gotcha's that I will run into. I am not sure why soft links don't work
for invoking it when they do
for the 32 bit system.
Cheers,
Peter
Summary:
On the Centos 64 bit linux system I'm running, in order for tclsh8.4
to be insensitive to the LD_LIBRAY_PATH
setting it needs to have only DT_RPATH set, not both DT_RPATH and
DT_RUNPATH. For comparison, on the 32 bit
system I'm using, the ActiveTcl tclsh8.4 has only the DT_RPATH set.
This is also true for 8.5.2.0.
64 bit system 32 bit system
LD_LIBRARY_PATH LD_LIBRARY_PATH
conflict no conflict conflict no conflict
DT_RUNPATH DT_RUNPATH DT_RUNPATH DT_RUNPATH
tclsh8.4 run via set !set* set !set* !set* !set*
---------------- ---- ----- ---- ----- ----- -----
soft link no-1 no-2 no-2 no-2 yes yes
script no-1 yes yes yes yes yes
directly no-1 yes yes yes yes yes
no-1 means that the conflicting (out of date) tclsh8.4.so library from
LD_LIBRARY_PATH was picked.
no-2 means that tcl couldn't find an init.tcl.
yes means that it worked as expected.
* the DT_RUNPATH was unset by changing the tag type from 0x1d to 0x0f
in the dynamic section of tclsh
to make it look like a second DT_RPATH (see readelf -d tclsh8.4)
In both of the above cases I believe I had LD_LIBRARY_PATH unset when
I did the ActiveTcl
install but there is a chance I am wrong there so I can't be certain
what effect if any
there is.
I haven't quite drilled down to why the softlink approach works for
the 32 bit system
but not for the 64 bit system.
The rest of this stuff just captures what I ran on the 64 bit system
to produce the summary above.
64 bit system:
> uname -s -r -v -m -p -i -o
Linux 2.6.9-78.0.13.ELsmp #1 SMP Wed Jan 14 15:55:36 EST 2009 x86_64
x86_64 x86_64 GNU/Linux
32 bit system:
> uname -s -r -v -m -p -i -o
Linux 2.6.9-22.0.1.EL #1 Thu Oct 27 12:26:11 CDT 2005 i686 i686 i386
GNU/Linux
> man ld.so on my systems gives:
...
The shared libraries needed by the program are searched for in
various places:
o (ELF only) Using the DT_RPATH dynamic section attribute
of the binary if present and DT_RUNPATH attribute does not exist. Use
of DT_RPATH is deprecated.
o Using the environment variable LD_LIBRARY_PATH. Except
if the executable is a setuid/setgid binary, in which case it is
ignored.
...
It was because of the first bullet that I tried getting rid of the
DT_RUNPATH. Then, when trying
this on the 32 bit system I saw that DT_RUNPATH wasn't used in that
tclsh.
The directory structure used has ActiveTcl installed in an
architecture specific directory and then a softlink back to the tclsh
in the
install bin directory is placed in a standard architecture specific
bin directory that is everyone's path. This worked on the 32 bit
system for 8.4 and on the 64 bit system for 8.5. We then needed 8.4 on
the 64 bit system and that was when things got messy.
To create the left hand portion of the summary table above I did the
following:
Create a new version of tclsh8.4 by editing it to have two RPATH
entries instead of
an RPATH and a RUNPATH entry. (I used xxd tclsh8.4 > hd; vim hd; xxd -
r hd > newtclsh8.4)
~/local/ActiveTcl8.4.19.1-x86_64/bin {289}> readelf -d tclsh8.4 | grep
PATH
0x000000000000000f (RPATH) Library rpath: [/home/user/
local/ActiveTcl8.4.19.1-x86_64/lib]
0x000000000000001d (RUNPATH) Library runpath: [/home/user/
local/ActiveTcl8.4.19.1-x86_64/lib]
~/local/ActiveTcl8.4.19.1-x86_64/bin {290}> readelf -d newtclsh8.4 |
grep PATH
0x000000000000000f (RPATH) Library rpath: [/home/user/
local/ActiveTcl8.4.19.1-x86_64/lib]
0x000000000000000f (RPATH) Library rpath: [/home/user/
local/ActiveTcl8.4.19.1-x86_64/lib]
~/local/ActiveTcl8.4.19.1 <- ActiveTcl 64 bit install directory
Created 4 executable files in a local bin directory in my path:
=================================================================
~/local/bin/script_tclsh8.4* (a csh script that directly runs
the ../ActiveTcl8.4.19.1/bin/tclsh8.4)
~/local/bin/script_newtclsh8.4* (a csh script that directly runs
the ../ActiveTcl8.4.19.1/bin/newtclsh8.4)
~/local/bin/sl_tclsh8.4 (a soft link -> ../
ActiveTcl8.4.19.1-x86_64/bin/tclsh8.4*)
~/local/bin/sl_newtclsh8.4 (a soft link -> ../
ActiveTcl8.4.19.1-x86_64/bin/newtclsh8.4*)
with LD_LIBRARY_PATH set
=================================================================
~/local/bin {281}> echo $LD_LIBRARY_PATH
/tools/ecad/local/x86_64/lib:/usr/lib64:/lib64:/tools/ecad/LMC/lib/
x86_linux.lib
soft link pointing to tclsh with RPATH and RUNPATH
-------------------------------------------------------------
~/local/bin {282}> ./sl_tclsh8.4
% info library
/usr/share/tcl8.4
soft link pointing to tclsh with only RPATH
-------------------------------------------------------------
~/local/bin {283}> ./sl_newtclsh8.4
application-specific initialization failed: Can't find a usable
init.tcl in the following directories:
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib /home/user/local/
lib/tcl8.4 /home/user/lib/tcl8.4 /home/user/local/library /home/user/
library /home/user/tcl8.4.19/library /home/tcl8.4.19/lib
This probably means that Tcl wasn't installed properly.
script pointing to tclsh with RPATH and RUNPATH
-------------------------------------------------------------
~/local/bin {284}> ./script_tclsh8.4
% info library
/usr/share/tcl8.4
script pointing to tclsh with only RPATH set
-------------------------------------------------------------
~/local/bin {285}> ./script_newtclsh8.4
% info library
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib/tcl8.4
directly running tclsh with RPATH and RUNPATH
-------------------------------------------------------------
~/local/ActiveTcl8.4.19.1-x86_64/bin {258}> ./tclsh8.4
% info library
/usr/share/tcl8.4
directly running tclsh with only RPATH set
-------------------------------------------------------------
~/local/ActiveTcl8.4.19.1-x86_64/bin {259}> ./newtclsh8.4
% info library
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib/tcl8.4
with LD_LIBRARY_PATH unset
=================================================================
> unsetenv LD_LIBRARY_PATH
soft link pointing to tclsh with RPATH and RUNPATH
-------------------------------------------------------------
~/local/bin {294}> ./sl_tclsh8.4
application-specific initialization failed: Can't find a usable
init.tcl in the following directories:
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib /home/user/local/
lib/tcl8.4 /home/user/lib/tcl8.4 /home/user/local/library /home/user/
library /home/user/tcl8.4.19/library /home/tcl8.4.19/lib
This probably means that Tcl wasn't installed properly.
soft link pointing to tclsh with only RPATH
-------------------------------------------------------------
~/local/bin {295}> ./sl_newtclsh8.4
application-specific initialization failed: Can't find a usable
init.tcl in the following directories:
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib /home/user/local/
lib/tcl8.4 /home/user/lib/tcl8.4 /home/user/local/library /home/user/
library /home/user/tcl8.4.19/library /home/tcl8.4.19/lib
This probably means that Tcl wasn't installed properly.
script pointing to tclsh with RPATH and RUNPATH
-------------------------------------------------------------
~/local/bin {296}> ./script_tclsh8.4
% info library
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib/tcl8.4
script pointing to tclsh with only RPATH set
-------------------------------------------------------------
~/local/bin {300}> ./script_newtclsh8.4
% info library
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib/tcl8.4
directly running tclsh with RPATH and RUNPATH
-------------------------------------------------------------
~/local/ActiveTcl8.4.19.1-x86_64/bin {266}> ./tclsh8.4
% info library
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib/tcl8.4
directly running tclsh with only RPATH set
-------------------------------------------------------------
~/local/ActiveTcl8.4.19.1-x86_64/bin {267}> ./newtclsh8.4
% info library
/home/user/local/ActiveTcl8.4.19.1-x86_64/lib/tcl8.4
qrs...@gmail.com
version of the 32 bit tclsh8.4, I didn't edit it to remove it.
Summary:
On the Centos 64 bit linux system I'm running, in order for tclsh8.4
to be insensitive to the LD_LIBRAY_PATH setting it needs to have only
DT_RPATH set, not both DT_RPATH and DT_RUNPATH. For comparison, on
the 32 bit system I'm using, the ActiveTcl tclsh8.4 has only the
DT_RPATH set. This is also true for 8.5.2.0.
64 bit system 32 bit system
LD_LIBRARY_PATH LD_LIBRARY_PATH
conflict no conflict conflict no conflict
DT_RUNPATH DT_RUNPATH DT_RUNPATH DT_RUNPATH
tclsh8.4 run via set !set* set !set* !set !set
Andreas Kupries
Do I read this right that the tclsh on 64 bit has to @__...__@
placeholders and only one them should be set to the installation path
? And even then it won't start properly if invoked through a symbolic
link ?
Meh. It is for the latter, proper invokation through a symbolic link
that we do all this binary patching. Seems I have to go over this
again.