Building error

Abdullah,

I’m glad to see that you’ve already tried the advice I gave that other user. It’s not clear to me you’ve convinced SCons to try using 4.1. Try a couple of things:

A) type “which gcc-4.1” into the command line. It should return something like “/usr/X11R6/bin/gcc-4.1”. This means you did get gcc-4.1 installed properly.

try overriding the cxx_ver flag with user.settings instead of on command line. Go to the file tools/build/user.settings. Look for the second “overrides”. Add these lines:
“cc” : “gcc-4.1”,
“cxx” : “g++-4.1”,

gcc 4.2 should work as well as 4.1 if that helps.

If this advice fails, let me know, I’ll ping the developer list to see if anyone else is using 10.10 yet.

In your Rosetta code directory, you should have directories bin, build, src, test, tools, and a few others. It’s THAT tools. (rosetta code directory)/tools/build/user.settings.

Can you get 4.2 instead of 4.1? It ought to work as well. Compiling the compiler is a nontrivial task, it is likely to be easier to fiddle with sasa.cc instead.

I asked around and found there’s a commit to the developers’ trunk (38831) that probably addresses this. If you can’t get 4.2 installed, give me your email address and I will get you replacement copies of sasa.cc and sasa.hh that (might) work. (We might have to fiddle with them a little more to accommodate changes made between 3.1 and two months ago.)

Is there any plans to provide snapshot of the development version or read access to the svn repro. I am also having problem compiling Rosessta 3.1 with gcc 4.5 in Fedora. Are there any plans to provide any patch for gcc 4.4 and above. My e-mail adresse is knutjorgen(at)gmail.com.

It is believed, but not guaranteed, that 3.2 will compile on those architectures.

Under the assumption that your error is also in sasa.cc, I have emailed you a different version of the file that might fix it.

I assume you mean that it stops ~compiling~ when working through the archive manager. There’s no way to build just the executeables you want without building the underlying libraries. We’re making the libraries less tightly linked together as we go (and a dependency of InterativeAbinitio on ArchiveBase is likely to be considered a problem, once we get as far as protocols).

Go ahead and continue commenting out files that won’t compile (IterativeAbrelax.hh/cc, etc). Let me know what your total list is and I’ll tell you if you should be worried.

You can also trying dummying out functions in the archive manager by deleting the guts of functions bodies in the cc file it fails on and replacing them with something simple (return, or return followed by a constructor for whatever variable it’s supposed to return ought to work).

I can’t reproduce your error or I’d give you a patch that will fix it…

“scons: done building targets” means you’re golden. score_jd2 is irrelevant, the order that the apps compile in is not important.

It’s almost impossible to have Rosetta compile, but not compile right. (that said, we had a nagging issue in the options parser for a year…)

Several testing suites are embedded in the release. None are really meant for end-user use but there’s no reason you can’t use them.

A) unit tests

The unit tests suite (most of the code in the test/) directory are, well, unit tests. Check Wikipedia. Our test coverage is quite poor, but these tests have KNOWN answers constant across all systems. Those answers are embedded in the tests. To run the unit tests, you’ll need to compile them and then run them. They are “supposed” to run in debug mode (30 mins to run tests):

scons (to compile the debug libraries)
scons cat=test (to compile the tests)
cd to rosetta_source
test/run.py -database (database) -mute all

It’s usually faster in release mode (a few mins to run tests):
(scons mode=release not necessary, since you already compiled)
scons cat=test mode=release
modify test/run.py to use release executeables; look for the system call to scons then add mode=release to that line
test/run.py -database (database) -mute all

Results should look like:

---

Unit test summary

---

Total number of tests: 698
number tests passed: 698
number tests failed: 0
Success rate: 100%

---

End of Unit test summary
Except that you’ll have fewer tests than that.

Integration tests
These tests run short Rosetta protocols (mostly too short to produce useful results, but long enough to put the code through its paces). Rosetta is unavoidably sensitive to numerical noise, so these trajectories are not guarunteed to match across different hardware (so we don’t distribute what it “should” look like). You can run them with:

cd test/integration
integration.py -j(num procs) -d database

It will report a “failure” in that it doesn’t have both a ref and new directory to compare, but you can look around in the ref directory to ensure that all the tests produce something that resembled useful results (usually a PDB or silent file). If you run the script twice, it should report perfect success (comparing new to ref on your machine). It should take about 30 seconds per test to run, but you can multithread it with -j.

C) Scientific tests

We also have scientific tests, which attempt to measure if Rosetta is doing things “right”. These test objective measures like sequence recovery in design, or RMSD in structure prediction. Go to test/scientific. I think the scientific.py script will run it. This takes hours and hours and hours.

Hi

I’ve been having the same error when i try to build rosetta 3.1. should i try to change the gcc??

You can try a different compiler/version.

If it is failing on sasa.cc, post your email and I’ll send along the patch. You can also try stubbing out the function if you don’t need SASA values.

If it is failing on the MPI archive stuff, follow the advice above.

If those bits of advice fail, feel free to ask again. Go ahead and create your own thread so I can keep failure cases separate.