Cannot run "Executable Starkits" on Linux (64-bit)

[damo]

I downloaded the "Executable Starkit" for Linux (Fedora 15 64-bit) and when I ran the "gorilla1535.bin" I got this:

This application requires Tk 8.5, which does not seem to be available.
couldn't load file "/tmp/tclYO4HoG": libXss.so.1: cannot open shared object file: No such file or directory

I got the same thing for the "gorilla1534.bin" file. I have an older "gorilla1533.bin" that I downloaded from the older site and that works fine. The old file is also about 400kB bigger than the two new ones.

I tried running from source, but it crashes when it times out and tries to lock itself. To run it, I had to install "tk" and "itcl", so when running the above binaries, which are supposed to include Tk 8.5, I already have Tk 8.5 installed and they still don't work.

Any ideas?

[zdia]

As I am working on a 32-bit Linux I can give only theoretical comments.

The tclkit is supposed to work on 64-bit Linux platforms, too. I would think that Fedora lacks the specified X11 library libXss.so.1

Perhaps this post can help in this issue (http://lists.fedoraproject.org/pipermail/users/2010-February/366776.html)

Topic: [SOLVED] Skype can't find libXss.so.1

I really, really wanted to use Skype on Fedora so I tracked down the missing dependency: on Fedora it is called libXScrnSaver. If you're running 64-bit as I am, it's not enough to have the 64-bit libXScrnSaver installed, you need to do:

yum install libXScrnSaver.i586

Despite the totally different library filename, it satisfies the dynamic link, and Skype launches right up!

Supposed you have installed a 64-bit version of Tcl/Tk, e.g. from ActiveState, then all necessary libs should have been installed. It seems that Fedora doesn't install the 32-bit version of libxss or perhaps libxss isn't installed at all.

What is saying "locate libxss" or "locate libXScrnSaver" on your system?

[rich123]

First question - Is Fedora 15 64-bit a combination 32/64-bit setup or a pure 64-bit only setup? I ask because as Zbigniew has already pointed out, these types of errors with the starpacks are often caused my a missing library of the correct bit-size (in this case, a missing 32-bit lib).

The executable starkits are for 32-bit systems. On my 64-bit Slackware they will not even start (Slackware 64 is a pure 64-bit system, only 64-bit binaries).

But, in any case, my larger concern is the crash when it attempts to lock itself when running the source. If you can give us more info on what happens then, and if we can fix that issue, you can run the source on 32 or 64 bit systems (that I how I run Gorilla on my 64-bit Slackware, using the source, but then being one of the devs, I should be using the source copy anyway....).

[damo]

I only started using Fedora 15 for the first time last week (I'd been using Debian/Kubuntu for about a decade), so I don't really know what sort of 32-/64-bit mix is in Fedora. I got Flash Player 32-bit working in FF4 by installing both 32-bit and 64-bit versions of some libraries, but, apart from that, I think it is mostly 64-bit. I'll count....

OK, of the packages I have installed, 1,039 are 64-bit, 77 are 32-bit (mostly related to the Flash install and most seem to have a 64-bit version installed, too) and 200 are "noarch" (config files, fonts, etc.).

The thing with the starkits is that I have an older "gorilla1533.bin" starkit that works fine with my current set-up. As I mentioned, it is about 400kB larger than the "gorilla1534.bin" and "gorilla1535.bin" starkits that are available for download from this GitHub project. I was under the impression that these starkits are supposed to include all the necessary libraries, though I suppose there is a limit to how far you can go with that. Anyway, it has something that the other don't that seems to make the difference.

Anyway, I installed the "libXScrnSaver.i686" package and the newer starkits at least launch now (good catch). I could run from source before installing this library, so I guess it was using the 64-bit one already installed. However, I get the same problem with the new starkits as I do with the source version: when the idle time out is fired, I get this message in a dialog box:

window name "right" already exists in parent
window name "right" already exists in parent
    while executing
"ttk::frame $top.right -padding {10 10}"
    (procedure "LockDatabase" line 81)
    invoked from within
"LockDatabase"
    (procedure "::gorilla::IdleTimeout" line 2)
    invoked from within
"::gorilla::IdleTimeout"
    ("after" script)

When I close the error dialog, the main PG window is (according to xwininfo) just a blank grey 200x200 square with the window ID "lockedDialog". The only way to recover is to close it and launch PG again. Actually, closing the dialog doesn't stop the process, I have to go and kill it the hard way. This doesn't happen with the older "gorilla1533.bin" starkit; it works OK when there is a time out.

Just a hint for testing: I had no problems running 64-bit Kubuntu 11.04 as a guest in a VirtualBox VM on top of a 32-bit Kubuntu 10.10 host last week. Perhaps that might be an easy way for you to try out a 64-bit environment for some testing, or to build 64-bit starkits.

[rich123]

Given what you write, Fedora 15 appears to be a mixed lib 32/64 system.

The starkits carry the Tcl and Tk runtimes (for those that do not have a Tcl or Tk runtime installed for whatever reason). libXscrnSaver is an X11 library, the starkits do not carry all the X11 libs, they run just like every other dynamic linked X program, they use the libs already installed. But the starkits are also 32-bit executables, which means you need all of the necessary 32-bit X11 libraries installed to get them to launch.

I am uncertain why the older 1533 starkit runs fine. Maybe the newer starkit exe's are linked to more libs. Try doing "ld gorilla1533.bin" from a shell, it will tell you what libraries it links to, you will likely find no XScrnSaver lib linked in. That would mean the newer startkit exe packs are now linking to XScrnSaver as well. Which would cause this particular issue.

As to the locking issue, there appears to have been a bug introduced in the merge of pre-release and master to make the release. But I have more investigating to do to verify that fact.

[rich123]

New commit dac1d373692dd75e1797 on the master branch should fix the error message on lock issue you noticed. If you want to try the source you can check out a .zip or tar.gz of the source based upon that commit by first viewing the commit itself, pushing the download button, and picking the download tar.gz or download .zip buttons.

[damo]

I ran "ldd" (I don't know where "ld" is in Fedora) and I got this for my working "gorilla1533.bin":

    linux-gate.so.1 =>  (0x00f53000)
    libdl.so.2 => /lib/libdl.so.2 (0x49074000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00312000)
    libm.so.6 => /lib/libm.so.6 (0x49366000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4959d000)
    libc.so.6 => /lib/libc.so.6 (0x48ee7000)
    /lib/ld-linux.so.2 (0x48ec6000)

When I ran it against the other two "bin" files, I just got "not a dynamic executable", nothing else. When I ran "file" against the new "bin" files, I got this:

gorilla1534.bin: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, corrupted section header size
gorilla1535.bin: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, corrupted section header size

for the old one I got this:

 gorilla1533.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

I'll try out the source tomorrow and see if it works for me.

[zdia]

@damo

window name "right" already exists in parent

Ok, this is a bug. I could reproduce it with my 32bit system. As Richard already mentioned widget definitions were duplicated by the release merge and so Tk tried to define twice a "window name".

In regard to running a 64bit Linux in a 32bit Virtualbox I was not lucky. It is not possible to set the virtualization flag in the bios of my Acer notebook although the processor is able for VT. Without this flag a 32bit Virtualbox will not allow to run a 64bit Linux.

Your observations in regard to the linking mode are very interesting. Indeed 1.5.3.3 was compiled with a tclkit 8.5.7 and the newer ones with tclkit 8.5.9. I will send a post to the tclkit forum to get more information about this topic.

[damo]

The virtualisation worked for me on an AMD Athlon II X4 640; maybe your chip is a bit different. I seem to remember there was some VirtualBox option I had to enable to make it all work. No matter, though, as you could reproduce the main problem anyway.

I tried out the latest source just now (commit dac1d37) and the time-out behaviour seems fine (although I changed it from 5 mins to 1 min but it still took 5 mins to time out). However, as the older "bin" is the only one that I can be sure will work across the different versions of Linux that I use when I run it off a USB key, I'll stick with that version for now.

Thanks for your help.

[rich123]

(although I changed it from 5 mins to 1 min but it still took 5 mins to time out).

The preferences setting of timeout under the File->Preferences dialog only effects newly created databases. The timeout value for a particular .pwsafe file is stored in that .pwsafe file, and can be adjusted via the Security->Customize menu entry.

This is a longstanding setting from when Gorilla's original author was also its maintainer. I can only surmise a reason but I suppose it is to allow for differing timeouts per .pwsafe file depending upon the sensitivity of the passwords stored therein.

However, as the older "bin" is the only one that I can be sure will work across the different versions of Linux that I use when I run it off a USB key, I'll stick with that version for now.

If you are running exclusively from multiple Linux machines, you can also run the source bundle from a USB stick as well. All you would need to have is Itcl installed on each Linux machine you use and the source bundle should run just fine from a USB key. Alternately, you can install Gorilla directly upon each machine, but keep your .pwsafe file on the USB key. Be careful to always save changes to the USB stick before unplugging if you do use this second option. Gorilla does not make any attempt to provide support for plural running instances to share access to a single .pwsafe file.

As a third option, the "Merge" functionality in Gorilla is intended to help with keeping multiple machine's .pwsafe files synchronized. Just install Gorilla and a .pwsafe file on each machine, then periodically copy the .pwsafe files back and forth and "Merge" them with each other. That is what I do among my three different Linux machines that I have Gorilla installed upon.

[zdia]

@damo:

You are welcome.

I think in regard to the 64bit issue on pure 64bit Linux machines there will be a solution: The ActiveState community edition includes 64bit tclkits. A "hello world" kit was running immediately on my (freshly installed) Salix (Slackware 13.37) machine. If you have enabled notifications for this issue than you will get an email when the first trial version will be ready.

[zdia]

@damo:

I have made a dynamically linked starpack with an older tclkit 8.5.1 which you can download from

http://zdia.de/packages/gorilla/gorilla.dyn

Note:

$ file gorilla.dyn 
gorilla.dyn: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped

But as Richard already told the kit will not even launch on my pure 64bit Salix despite the fact that it is dynamical. So probably Richard's proposition to synchronize the USB Gorilla databases with those on the various desktop platforms (Linux/Windows/MacOSX 32/64bit) by merging them will be the most practical way.

For your 64bit Fedora you can try the following executable with integrated 64bit versions of sha256 and twofish:

http://zdia.de/packages/gorilla/1.5.3.5/gorilla1535.bin64

[zdia]

With version 1.5.3.6 there will be two versions, linked statically and with correct header by tclkit 8.5.11:

file gorilla.bin gorilla.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped

$ file gorilla.bin gorilla.bin: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped