spin hangs on

  • Jake


    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:
      cd $dir
      which originally were
      cd "$dir"
      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.

      Dave Spencer
      Dalhousie University
      Halifax, Nova Scotia

    • James Bonfield
      James Bonfield

      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.