Member Site › Forums › Rosetta 3 › Rosetta 3 – Build/Install › Rosetta 3.4 build error with
- This topic has 17 replies, 6 voices, and was last updated 12 years, 5 months ago by Anonymous.
-
AuthorPosts
-
-
April 17, 2012 at 11:11 pm #1240
I’ve been trying to build Rosetta 3.4 on Ubuntu 10.04. I’ve tried compiling with both gcc 4.4.3 and 4.3.4. Both give me the following error:
src/protocols/canonical_sampling/ParallelTempering.cc: In member function ‘virtual void protocols::canonical_sampling::ParallelTempering::finalize_simulation(core::pose::Pose&, const protocols::canonical_sampling::MetropolisHastingsMover&)’:
src/protocols/canonical_sampling/ParallelTempering.cc:193: error: size of array ‘exchange_accepts_’ has non-integral type ‘std::pair‘
scons: *** [build/src/release/linux/2.6/64/x86/gcc/4.4/protocols/canonical_sampling/ParallelTempering.os] Error 1
scons: building terminated because of errors.Does anyone have any ideas of what could be causing this? Thank you much for your help.
-
April 17, 2012 at 11:56 pm #6978Anonymous
No idea what’s causing it, beyond “different versions of GCC behave differently”.
Looking at the code,the first thing I’d try to fix it is to add “#include
-
June 29, 2012 at 3:17 pm #7358Anonymous
I am having the exact same problem with Ubuntu 10.04 and gcc 4.4.3. Since it’s a bit involved to install gcc 4.5, I’d be grateful if someone could show me how, in excruciating detail, to dummy out the offending code. Needless to say I’m a total noob at Rosetta and Ubuntu. TIA
-
June 30, 2012 at 12:23 am #7366Anonymous
Thanks very much. It compiled with the fix. Keep my fingers crossed and hope that it runs without a hitch. I put in the error message and commented out the block just in case someone like jadolfbr finds a fix for the bug.
-
July 11, 2012 at 5:20 pm #7397Anonymous
I hit this problem also (gcc 4.4.3).
I have no idea why the compiler is having trouble with type promotion, but the following work-around keeps it happy.
// EAM - modified to work around compiler glitch with gcc 4.4.3
for (core::Size i=0; istd::pair elem(i, i+1);
double a = exchange_accepts_[elem];
double b = exchange_attempts_[elem];
core::Real frequency(core::Real(a)/core::Real(b));
-
July 20, 2012 at 10:02 pm #7431Anonymous
Yes, it compiles also if I replace with
for (core::Size i=0; i<n_temp_levels()-1; ++i) {
std::pair<int, int> elem(i, i+1);
core::Real const a = exchange_accepts_[elem];
core::Real const b = exchange_attempts_[elem];
core::Real frequency(a/b);
-
April 18, 2012 at 1:37 am #6979Anonymous
I assume Steven meant “#include <map>”, (include the C++ map header) but the forum ate his angle brackets.
-
April 18, 2012 at 5:06 pm #6983
Thanks for the thought. I did try adding <map> into the headers list but the same error still came up. Any ideas why
exchange_attempts_
andexchange_accepts_
aren’t being recognized as maps? -
April 18, 2012 at 1:50 am #6980Anonymous
yep
-
April 18, 2012 at 5:19 pm #6984Anonymous
No to your actual question.
If this is code you don’t intend to use, I think it may dummy out safely. It’s got a hard exit if not compiled in MPI, so it’s clearly not a widely-accessed bit of code – as far as I can tell it’s only accessed through the Parser if you are deliberately doing the canonical sampling MC stuff. If you think you aren’t going to use it, (and if you don’t know you intend to, you aren’t), try dummying out the functions with the calls that won’t compile (or just replace the map indicies with 1 or something). The code won’t work that way, but if you aren’t using it anyway…
-
April 20, 2012 at 5:38 pm #6993
Dummying it out did allow the build to complete. I’m pretty sure I won’t be needing canonical sampling so that should work for now.
Thanks -
April 27, 2012 at 5:08 pm #7030Anonymous
Hi Steven,
I’m having the same issue with 10.04. How do I dummy out the functions with the calls that won’t compile? -
April 28, 2012 at 2:29 am #7031Anonymous
Well…you, I think, know the codebase well enough to hope that since you can reproduce the bug, you’d take a stab at fixing it
Failing that – just comment out anything that GCC will let you comment. You’ll need to make sure the function has legal return values, but short of that you can comment out pretty much any line in the functions with no issues. You should probably leave the header alone, but you can start by commenting out any line of code that contains the offending references to exchange_accepts_ and then see what else has to go to get it to compile.
I don’t have code in front of me, but it may be possible to just remove the whole block from compilation – remove it from whichever .src.settings file it appears in, and any init files it appear in. If I recall correctly this code is only used via parser, so removing it from the .src.settings file and the init files will cleanly remove it from the code base.
Keep me updated if it’s giving you trouble – this may not be the clearest advice I could give, it’s a little late…
-
May 2, 2012 at 2:12 am #7059Anonymous
Thanks Steven,
I wasn’t thinking about commenting out the function or removing it from src.settings in order to get it to run….wasn’t sure if ‘dummy’ it out was some fanciful scons or c++ term I had never heard of! I had trouble compiling rosetta3.3 as well, and was running into strange errors trying to get the fragment picker working as per brian’s tutorial on the wiki (CPU crashed and burned last week). I ended up upgrading to Ubuntu 12.04, and they both seem to be compiling fine with GCC 4.5…. -
June 29, 2012 at 5:17 pm #7361Anonymous
Simply open rosetta/rosetta_source/src/protocols/canonical_sampling/ParallelTempering.cc with your favorite text editor. Scroll down to about line 193. Then delete the “for {}” block:
for (core::Size i=0; istd::pair elem(i, i+1);
core::Real frequency(core::Real(exchange_accepts_[elem])/core::Real(exchange_attempts_[elem]));
tr << temperature(i+1) << " <-> ” << temperature(i+2) << ": " << frequency
<< " (" << exchange_accepts_[elem] << " of " << exchange_attempts_[elem] << ")" << std::endl;
}
… or better yet, replace it with the following code (so if for some reason you run something that depends that needs the deleted code, you’ll be told about it):
utility_exit_with_message( “Oops – tried to execute the code I edited out.” );
Save the file with the changes, and then re-try compiling. With any luck, things will compile. If not, try repeating the process in location of the new error.
-
July 11, 2012 at 7:27 pm #7398Anonymous
I am testing this against the development branch; assuming it doesn’t break anything I’ll put it in for 3.5.
-
July 11, 2012 at 7:43 pm #7399Anonymous
Does it work if you replace “double a” and b with “core::Real const a” and b? I don’t want to introduce direct use of double into the codebase if I don’t have to. The way you’ve casted it makes me think you have tried that and it failed. core::Real is typedef’d to double. (I don’t have a system where it’s broken to test against…)
-
July 21, 2012 at 5:50 pm #7435Anonymous
Excellent. It’s patched in the main codebase. Thanks!
-
-
AuthorPosts
- You must be logged in to reply to this topic.