Member Site › Forums › Rosetta 3 › Rosetta 3 – Build/Install › compile error on OS X Yosemite
- This topic has 6 replies, 2 voices, and was last updated 8 years, 11 months ago by
Anonymous.
-
AuthorPosts
-
-
September 20, 2015 at 11:27 pm #2290
Anonymous
I amt trying to install the lastest release of Rosetta on Mac OS Yosemite.
The build quits on the following error:
src/utility/thread/backwards_thread_local.hh:19:9: error: keyword is hidden by macro definition [-Werror,-Wkeyword-macro]
#define thread_local
^
1 error generated.
scons: *** [build/src/release/macos/10.10/64/x86/clang/7.0/default/apps/public/AbinitioRelax.o] Error 1
scons: building terminated because of errors.
I can’t seem to find any other references to this in the forum, so if anyone has ideas I would appreciate it.
On another note, would it be any better to install on a Linux OS in terms of compiling and ease of use?
Thanks!
-
September 20, 2015 at 11:41 pm #11224
Anonymous
Digging in a little bit, the backwards_thread_local.hh file seems to be the issue. Of course, I have no idea how to fix it.
The file is attached here as a .txt (rather than hh)
-
September 21, 2015 at 2:32 pm #11226
Anonymous
The “backwards” part of backwards_thread_local.hh means “backwards compatibility”. It’s intended to provide support (more or less) for the new thread_local keyword for compilers which don’t support it. The detection logic we use is crude, primarily because it’s hard to detect the compiler support for the keyword directly. So some compilers (like yours) can have the keyword on even when it’s not supposed to.
The fix is simple – just delete the line “#define thread_local” from backwards_thread_local.hh and recompile.
Regarding MacOS and Linux, there shouldn’t be a big difference between the two, in terms of ease-of-use. (It should be equivalently difficult to use and understand on both.) Many of the major Rosetta developers do all their development on Macs. Other’s do it on Linux. For running on a single machine, both should be very similar. The big benefit that Linux has is that large computer clusters are normally running Linux machines, rather than Macs. So when you go for large production runs, you normally run on Linux machines – but that’s because that’s what the clusters are running, rather than any intrinsic benefit on Rosetta’s side.
-
September 21, 2015 at 11:37 pm #11232
Anonymous
Thanks for taking a look.
deleting that line resulted in a new error at the same point:
src/protocols/jobdist/Jobs.hh:31:8: error: thread-local storage is not supported
for the current target
static thread_local basic::Tracer jobs_tracer( “protocol.jobdist.jobs.hh” );
^
1 error generated.
scons: *** [build/src/release/macos/10.10/64/x86/clang/7.0/default/apps/public/AbinitioRelax.o] Error 1
src/protocols/match/output/MatchProcessor.cc:40:8: error: thread-local storage
is not supported for the current target
static thread_local basic::Tracer TR( “protocols.match.output.MatchProcessor” );
^
1 error generated.
scons: *** [build/src/release/macos/10.10/64/x86/clang/7.0/default/protocols/match/output/MatchProcessor.os] Error 1
scons: building terminated because of errors.
-
September 22, 2015 at 7:09 pm #11237
Anonymous
The strategy under #4 appears to have worked. At least I finally got to the “Done building targets” step.
Thanks for the help sorting this out.
-
September 21, 2015 at 4:53 pm #11227
Anonymous
Spoke too soon. Apparently just removing the line doesn’t work, as on some machines thread_local results in an error.
What you want to do instead is leave backwards_thread_local.hh as it is, and then edit the file main/source/tools/build/basic.settings at about line 1945, (in the “clang, macos” block) changing:
# There is at least one variable only used on non-Macs.
"warn" : ["Wno-unused-variable"],into:
# There is at least one variable only used on non-Macs.
"warn" : ["Wno-unused-variable", "Wno-keyword-macro"], -
September 22, 2015 at 3:24 pm #11233
Anonymous
Yeah, sorry. For the initial comment I didn’t realize that the new Xcode compilers also have issues with thread_local. The edits to main/source/tools/build/basic.settings should correct the issue (as long as you return backwards_thread_local.hh to the original version.)
-
-
AuthorPosts
- You must be logged in to reply to this topic.