Is there a 64-bit Linux tclkit 8.5.9?
Zbigniew Diaczyszyn
does not list a 64-bit version for Linux.
Maybe anybody compiled a 64-bit version?
Zbigniew
Harald Oehlmann
http://sourceforge.net/projects/kbskit/files/kbs/0.4.1/
-Harald
Pat Thoyts
Mostly people use 32 bit versions as there is not that much to be
gained by running a 64 bit tcl process and 64 bit operating systems
are all quite happy to run 32 bit processes. ActiveTcl provides 64 bit
versions of their basekits which are tclkits by another name. If you
are using 64bit active tcl then the wrapping utilities will ensure
that 64 bit extensions are also wrapped. Otherwise, you have to ensure
any extensions are 64 bit shared objects.
Zbigniew Diaczyszyn
>> Maybee you like those from Rene Zaumseil:
>> >
>> > http://sourceforge.net/projects/kbskit/files/kbs/0.4.1/
>> >
>> > -Harald
> ... ActiveTcl provides 64 bit
> versions of their basekits which are tclkits by another name. If you
> are using 64bit active tcl then the wrapping utilities will ensure
> that 64 bit extensions are also wrapped. Otherwise, you have to ensure
> any extensions are 64 bit shared objects.
>
Thanks for the hints. I will try to build my package with them.
> Mostly people use 32 bit versions as there is not that much to be
> gained by running a 64 bit tcl process and 64 bit operating systems
> are all quite happy to run 32 bit processes.
True, that's the reason why I still work on a 32-bit Slackware Linux.
But the number of the 64-bit users is increasing and e.g. the Slackware
64-bit version is a pure 64-bit implementation so a 32bit tclkit will
not even launch.
An user of my app remarked that old versions I compiled with tclkit
8.5.7 are shared libraries (which had no problems to launch on 64bit
system):
> $ ldd gorilla1533.bin
> linux-gate.so.1 => (0xb7822000)
> libdl.so.2 => /lib/libdl.so.2 (0xb7806000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7716000)
> libm.so.6 => /lib/libm.so.6 (0xb76f0000)
> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb76d3000)
> libc.so.6 => /lib/libc.so.6 (0xb756f000)
> /lib/ld-linux.so.2 (0xb7823000)
whereas the new versions compiled with tclkit 8.5.9:
> tclkit sdx.kit wrap gorilla.bin -runtime tclkit-8.5.9-linux
seem to be static:
> $ ldd gorilla1535.bin
> not a dynamic executable
Looking for information in gorilla1535.bin shows:
> gorilla1534.bin: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, corrupted section header size
Corrupted header size???
Is there a way to get a dynamic version?
Zbigniew Diaczyszyn
http://tclkit.googlecode.com/files/tclkit-8.5.9-linux-ix86.gz
By name it seems to be dynamic but:
> $ file tclkit-dyn-8.5.9
> tclkit-dyn-8.5.9: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, corrupted section header size
Pat Thoyts
It is probably just upx compressed. If you run upx -d on the
executable then the bintools can see the real contents. If you want a
tclkit that is not upx compressed you can use sdx mksplit to break it
into the exe and database parts, upx decompress the .head part and
then rejoin the two (cat tclkit.head tclkit.tail > tclkit-noupx)
Zbigniew Diaczyszyn
> It is probably just upx compressed. If you run upx -d on the
> executable then the bintools can see the real contents.
I got the following result:
> $ upx -d -o tclkit-8.5.9 tclkit-dyn-8.5.9
> Ultimate Packer for eXecutables
> Copyright (C) 1996 - 2010
> UPX 3.07 Markus Oberhumer, Laszlo Molnar & John Reiser Sep 08th 2010
>
> File size Ratio Format Name
> -------------------- ------ ----------- -----------
> upx: tclkit-dyn-8.5.9: CantUnpackException: header corrupted 2
Jeff Hobbs
>> Mostly people use 32 bit versions as there is not that much to be
>> gained by running a 64 bit tcl process and 64 bit operating systems
>> are all quite happy to run 32 bit processes.
FWIW, 64-bit exes on a 64-bit system are actually 5+% faster due to
compiler opts for the newer arch.
> True, that's the reason why I still work on a 32-bit Slackware Linux.
> But the number of the 64-bit users is increasing and e.g. the Slackware
> 64-bit version is a pure 64-bit implementation so a 32bit tclkit will
> not even launch.
Yes, we've seen the same, in that newer 64-bit Linux OSes default
configs do not have the necessary support libs to run 32-bit exes.
However ...
> An user of my app remarked that old versions I compiled with tclkit
> 8.5.7 are shared libraries (which had no problems to launch on 64bit
> system):
>
>> $ ldd gorilla1533.bin
>> linux-gate.so.1 => (0xb7822000)
>> libdl.so.2 => /lib/libdl.so.2 (0xb7806000)
>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7716000)
>> libm.so.6 => /lib/libm.so.6 (0xb76f0000)
>> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb76d3000)
>> libc.so.6 => /lib/libc.so.6 (0xb756f000)
>> /lib/ld-linux.so.2 (0xb7823000)
>
> whereas the new versions compiled with tclkit 8.5.9:
>
>> tclkit sdx.kit wrap gorilla.bin -runtime tclkit-8.5.9-linux
>
> seem to be static:
>
>> $ ldd gorilla1535.bin
>> not a dynamic executable
>
> Looking for information in gorilla1535.bin shows:
>
>> gorilla1534.bin: ELF 32-bit LSB executable, Intel 80386, version 1,
>> statically linked, corrupted section header size
>
> Corrupted header size???
>
> Is there a way to get a dynamic version?
I'm suspicious that dynamic should work over static. The problem is
that it is the dynamic 32-bit base library set that isn't installed by
default. I would suspect that a truly static 32-bit exe should be fine,
but it might have to be static right down to the libc. In general, each
distro has its own (differently named of course) 32-bit compat libs that
can be installed if you just want to make that a requirement.
Jeff
Zbigniew Diaczyszyn
> versions of their basekits which are tclkits by another name. If you
> are using 64bit active tcl then the wrapping utilities will ensure
> that 64 bit extensions are also wrapped. Otherwise, you have to ensure
> any extensions are 64 bit shared objects.
>
Tried to wrap some "Hello world" starpack with sdx.kit and those
basekits on 32bit and on 64bit systems (Slackware 13.37): Running
without problems!
> $ file base-tk8.5-thread-linux-ix86
> base-tk8.5-thread-linux-ix86: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped
The same for ELF 64-bit. No corrupted header.
Thanks for the help.