uninstalling or rebuilding rosetta

[Anonymous]

Hi everyone,

I just received an allocation for 100,000 SUs on the xsede portal. I then transferred my copy of rosetta with protein models and scripts for running a lot of my models. Somehow the correct libraries are no longer found in the rosetta file. I would like to uninstall and rebuild the rosetta for two reasons, first I have five copies of the executable and I would like to clean it up. Second I think that this is the best way to replace the missing libraries. Does anyone have ideas or suggestions? The main reason I don’t want to scrap and unpack a new .tgz is I had to modify quite a few different .cc/.h files to get it working with my compilers.

Thanks,

Ryan

[Anonymous]

You cannot move compiled copies of Rosetta from one computer to another, because the linking step hard-codes the library paths.

You *should* clean your compiled copy and rebuild. The simplest way to do this is:
cd build
rm -rf external src (and whatever else is there)
cd ../bin
rm -rf *release *debug (and anything else)
cd ..
rm .sconsign.dblite

Then recompile. I do this all the time (I’ve done it today) and it’s very reliable for “moved” copies of Rosetta. It will have no effect on your minor changes in src/.

You can also try scons –clean, but it isn’t very reliable.

If you are *very confident* that the hardware architectures of the two machines (the one you compiled on and the new one) are identical, it is possible to simply recompile and SCons will automatically relink without doing expensive recompiling. I don’t suggest this unless recompiling is expensive for some reason.

[Anonymous]

Thank you for your help it worked, sorry for the late response I wanted to run a full prediction before I confirmed. Thank you again.

Ryan

[Anonymous]

Ok so i’ve done that but now when I’m rebuilding I’m getting an error with scons.

login4$ python scons.py bin mode=debug
Traceback (most recent call last):
File “scons.py”, line 187, in
import SCons.Script
ImportError: No module named SCons.Script

I have a file SConscript but I don’t think this is the module. do you know what this means?

Ryan

[Anonymous]

Another option is to compile Rosetta statically (add “extras=static” to the scons command line) on the machine it’s originally on and then move the static executable to the other computer (as the files in the bin directory are symlinks, you have to do something like “ls -l” to find and copy the targets, rather than just the symlink).

I’ve done this many times when I’ve wanted to run Rosetta on a cluster that isn’t really set up for compiling. You have to make sure that the systems are binary compatible (compiling on a Mac and then running on Linux probably wouldn’t be suggested), but the static linkage limits many library path loading issues.

[Anonymous]

A) Which directory is this in?

Is scons.py a symlink or a real file? If it’s not a symlink, that’s the problem…if you moved your Rosetta install in a way that replaced symlink with file targets, scons breaks. It may be repairable, but it’d be less error-prone to re-copy rosetta in way that preserves symlink status (man mv/cp/scp, or better yet tar it up)

[Author]

Posts