I tried to start spin today by typing "spin" on the command line and nothing happens - the cursor just pulses on new line. But to get back to working command line one needs to ctrl-c is first.
If the STADEN_DEBUG is set true, than these lines will appear before hang-up:
load libspin.so =>
load libitcl3.3.so =>
load libitk3.3.so =>
load libiwidgets.so => couldn't load file "libiwidgets.so": libiwidgets.so: cannot open shared object file: No such file or directory
load libspin_emboss.so => couldn't load file "libspin_emboss.so": libspin_emboss.so: cannot open shared object file: No such file or directory
Anybody any idea, what's going on?
Jakub, WGRC, K-State
Nothing has changed on your system that could have affected your setup? If files cannot found, then either they have been moved, they are no longer in your PATH, or the permissions have changed. First I would check for the presence of the 'missing' files.
As a followup to this thread:
I have this issue in MacOSX, 10.3.9, but I have never seen it before with Staden on OSX, and I don't recall seeing it on other platforms.
Incidentally it also affects 'create_emboss_files' but not 'trev', 'pregap4' or 'gap4'.
If you do essentially what the original poster says (I launch with 'spin&') you get the result he describes, and the shell prints that spin has stopped, and a 'ps', reveals that 'stash' and 'embossdata' are still running (and 'stash' indicates it was running 'spin.tcl'). However, if you cd into the directory containing the binaries, type 'spin' (or './spin') once, press <CR> the cursor moves to the next line, but if you press <CR> a second time 'spin' launches.
It was (I believe) after making a few minor, and probably irrelevant, changes to a few lines in 'spin', i.e., situations such as:
which originally were
I can now launch 'spin' from anywhere, but with two <CR> required.
If you type 'spin' outside of its home directory after producing the STOPPED condition then the name ('spin') is echoed on the next line.
I am very puzzled by this behaviour and I have tried troubleshooting it by no success yet.
I compared 'spin.tcl' in 1.6.0 to older versions but it doesn't seem to have changed, and I can't see any differences between 'spin' and say 'trev' that would suggest why one works correctly and the other doesn't.
I can find no indication of libraries named 'libiwidgets.dylib' (as they are called in MacOSX) or of 'libspin_emboss.dylib' in either 1.6.0 or in
2003.0b1. and 'grep' doesn't find any reference to these names in any binaries or libraries in Staden 1.6.0, 2003.0b1, nor the Solaris Staden 2002. So I don't know what is going on there.
Halifax, Nova Scotia
The iwidgets and spin_emboss dylib files don't exist. It's just a red herring. Normally of course you don't see how internally things work until STADEN_DEBUG is enabled, so it's not an issue. Basically the library loading code adds to the Tcl search path and also attempts to load the library (using the standard system search path, so it's hard to check for existance first). If the library doesn't exist because it's not meant to exist, then you'll still see the message.
Anyway, as for why Spin no longer works, I've no clue at all! Spin hasn't changed in ages.
If you've got a bash shell up and have set STADENROOT environment and sourced staden.profile, then you should be able to bypass the spin startup script and run "stash $STADLIB/spin/spin.tcl" directly. That's one level further along the startup process so it may help to diagnose where the fault lies.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.