Starkit causes suddenly ELF Header issue
Zbigniew Diaczyszyn
starkit on Linux and tries to perform:
package require <mypackage>
The catch command shows the following message:
couldn't load file "/tmp/tclEoKhjm": /tmp/tclEoKhjm: invalid ELF header
The tclkit version I am using (8.5.8) worked perfectly all the time and
just creating a *.kit version works fine, too:
tclkit sdx.kit wrap gorilla.kit
166 updates applied
tclkit gorilla.kit
But when I try:
cp tclkit tclkit2
chmod a+x tclkit2
./tclkit sdx.kit wrap gorilla.bin -runtime tclkit2
I get this mysterious error, also when I tried to use the latest build from:
http://www.patthoyts.tk/tclkit/linux-ix86/8.5.9/tclkit-8.5.9.gz
The auto_path seems well:
PATH/gorilla.bin/lib/app-gorilla/tooltip
Producing starkits for the MacOSX shows no problems at all
./tclkit sdx.kit wrap gorilla.aqua -runtime tclkit-8.5.9-macosx-universal
I wonder why Tcl is trying to load "/tmp/tclEoKhjm" instead of the file
indicated by pkgIndex.tcl?
Zbigniew Diaczyszyn
> My application is suddenly causing a load error when it is compiled as a
> starkit on Linux and tries to perform:
>
> package require <mypackage>
>
> The catch command shows the following message:
>
> couldn't load file "/tmp/tclEoKhjm": /tmp/tclEoKhjm: invalid ELF header
>
The issue seems to be caused by my application:
A starkit which contains just the line: "package require Itcl" is
executing well.
Pat Thoyts
Are you using 64bit linux? Make sure your package library is suitable
for the tcl executable you are using. You cannot load 64bit libraries
into 32 bit processes.
Or possibly you simply generated something that is not a shared object
(aka dll).
Also, to load an extension into a tclkit, the extension package must
have been compiled using Tcl stubs.
The tmp filename is because shared libraries are loaded by the
system's ld.so which doesn't understand tcl virtual filesystems. So we
copy the shared library out into the tmp directory and have that
loaded up.
Zbigniew Diaczyszyn
> Are you using 64bit linux? Make sure your package library is suitable
> for the tcl executable you are using. You cannot load 64bit libraries
> into 32 bit processes.
Yes there are 64bit libraries for the sha256 module present and I am
running a 32bit Linux:
$ tree -L 2 -F
.
|-- Darwin-x86/
| |-- critcl.tcl*
| `-- sha256c.dylib*
|-- Linux-x86/
| |-- critcl.tcl
| `-- sha256c.so*
|-- Linux-x86_64/
| |-- critcl.tcl
| `-- sha256c.so*
|-- Windows-x86/
| |-- critcl.tcl
| `-- sha256c.dll*
|-- critcl.tcl
`-- pkgIndex.tcl
[twofish]$ tree -L 1
.
|-- LICENSE.txt
|-- f32-Linux-x86.so
|-- f32-Linux-x86_64.so
|-- f32-critcl.tcl
|-- pkgIndex.tcl
|-- twofish.tcl
`-- twotest.tcl
I removed f32-Linux-x86_64.so and the folder Linux-x86_64 but I am
getting still the load error
> Or possibly you simply generated something that is not a shared object
> (aka dll).
> Also, to load an extension into a tclkit, the extension package must
> have been compiled using Tcl stubs.
Hm, Critcl made all the compiling stuff. I think it uses stubs per
default, doesn't it?
> The tmp filename is because shared libraries are loaded by the
> system's ld.so which doesn't understand tcl virtual filesystems. So we
> copy the shared library out into the tmp directory and have that
> loaded up.
>
Thank you for the hint. So probably on the Mac I had no problem because
Snow Leopard is per default running 64bit coded.
Although sha256c (tcllib) compiled well into a starkit. It is the
twofish extension which is newly added, so I will have a glance on it.
Zbigniew Diaczyszyn
that at first the application's local path was searched through. And
because there was an Itcl folder which offered only a "dylib" version of
Itcl so the Linux application could not load the shared library at
runtime and I've got an "ELF" error.
Copying the libitcl3.4.so to that folder and a little modification of
the pkgIndex.tcl made the starkit launch without problems:
package ifneeded Itcl 3.4 [list load [file join $dir "libitcl3.4[info
sharedlibextension]"] Itcl]