rosetta build error

[Anonymous]

Dear Rosetta users!

I am trying to build and use rosetta latest version but getting error while compiling source code with ./scons.py. 

the error file is attached herewith, kinldy try to help me out.

many thanks in advance!

malkeet

 

 

error log file is

genesis:/home/gnss/singhma> python -V

Python 2.6.6

genesis:/home/gnss/singhma> p27

[singhma@genesis ~]$ python -V

Python 2.7.13

[singhma@genesis ~]$ cd rosetta/software

[singhma@genesis software]$ ll

total 3020192

-rw-r–r– 1 singhma gnss  252221850 Jun  5 16:32 rosetta_3.8_user_guide.tgz

drwxr-xr-x 6 singhma gnss       4096 Feb 26 02:55 rosetta_src_2017.08.59291_bundle

-rw-r–r– 1 singhma gnss 2840439965 Jun  5 16:31 rosetta_src_3.8_bundle.tgz

[singhma@genesis software]$ cd rosetta_src_2017.08.59291_bundle/

[singhma@genesis rosetta_src_2017.08.59291_bundle]$ cd ma i n/source

bash: cd: ma: No such file or directory

[singhma@genesis rosetta_src_2017.08.59291_bundle]$ ./scons.py -j12 mode=release bin

bash: ./scons.py: No such file or directory

[singhma@genesis rosetta_src_2017.08.59291_bundle]$ cd main/source

[singhma@genesis source]$ ./scons.py -j12 mode=release bin

scons: Reading SConscript files …

Running versioning script … fatal: Not a git repository (or any of the parent directories): .git

Done. (0.0 seconds)

Number of option files updated: 0

Total 3922 options.

Finished updating ResidueProperty code — no changes needed

Finished updating VariantType code — no changes needed

scons: done reading SConscript files.

scons: Building targets …

g++ -o build/src/release/linux/2.6/64/x86/gcc/4.4/default/apps/public/AbinitioRelax.o -c -std=c++0x -ffor-scope -isystem external/boost_1_55_0/ -isystem external/ -isystem external/include/ -isystem external/dbio/ -pipe -Wall -Wextra -pedantic -Werror -Wno-long-long -Wno-strict-aliasing -march=core2 -mtune=generic -O3 -ffast-math -fno-finite-math-only -funroll-loops -finline-functions -finline-limit=20000 -s -Wno-unused-variable -Wno-unused-parameter -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS -DPTR_STD -DNDEBUG -Isrc -Iexternal/include -Isrc/platform/linux/64/gcc/4.4 -Isrc/platform/linux/64/gcc -Isrc/platform/linux/64 -Isrc/platform/linux -Iexternal/boost_1_55_0 -Iexternal/libxml2/include -Iexternal -Iexternal/dbio -I/usr/include -I/usr/local/include src/apps/public/AbinitioRelax.cc

In file included from src/utility/options/Option.hh:25,

                 from src/utility/options/OptionCollection.hh:23,

                 from src/basic/options/option.hh:17,

…

src/utility/signals/BufferedSignalHub.hh:124:   instantiated from ‘void utility::signals::BufferedSignalHub<ResultType, Signal>::unblock() [with ReturnType = void, Signal = core::pose::signals::DestructionEvent]’

src/utility/options/ScalarOption_T_.hh:155:   instantiated from here

/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_iterator.h:708: error: cannot increment a pointer to incomplete type ‘core::pose::signals::DestructionEvent’

scons: *** [build/src/release/linux/2.6/64/x86/gcc/4.4/default/protocols/mpi_refinement/MPI_Refinement.os] Error 1

scons: building terminated because of errors.

[singhma@genesis source]$

[singhma@genesis source]$

 

[Anonymous]

Your comment was long enough that it was breaking the forum software.  I edited out some of the error stream.

The problem is that GCC 4.4 is too old to compile Rosetta 3.8.  https://www.rosettacommons.org/docs/latest/build_documentation/Cxx11Support

[Anonymous]

Your comment was long enough that it was breaking the forum software.  I edited out some of the error stream.

The problem is that GCC 4.4 is too old to compile Rosetta 3.8.  https://www.rosettacommons.org/docs/latest/build_documentation/Cxx11Support

[Anonymous]

Your comment was long enough that it was breaking the forum software.  I edited out some of the error stream.

The problem is that GCC 4.4 is too old to compile Rosetta 3.8.  https://www.rosettacommons.org/docs/latest/build_documentation/Cxx11Support

[Anonymous]

Interesting.  These are the same errors you had with GCC 4.4.  I’d suspect something is going wrong in pathing and g++ still points to 4.4, perhaps?  What does “which g++” report?  What does “g++ –version” (or whatever its version flag is) report?

[Anonymous]

Interesting.  These are the same errors you had with GCC 4.4.  I’d suspect something is going wrong in pathing and g++ still points to 4.4, perhaps?  What does “which g++” report?  What does “g++ –version” (or whatever its version flag is) report?

[Anonymous]

Interesting.  These are the same errors you had with GCC 4.4.  I’d suspect something is going wrong in pathing and g++ still points to 4.4, perhaps?  What does “which g++” report?  What does “g++ –version” (or whatever its version flag is) report?

[Anonymous]

Hello!

 

Bingo!! Rosetta is compiled and working fine now!!!!

Thank you dear for your time and suggestions!

 

Malkeet

 

[Anonymous]

Hello!

 

How to use multiple cores for rosetta calculations?

and second is it possible to use GPUs for ddG calcultions in rosetta?

 

Thanks in advance!

Malkeet

[Anonymous]

Hello!

I have compiled the source of Rosetta suit, and downloaded the Linux binary file version too.

if i am using binary version for the protein preperation: it shows relax.static.linixgccrelease script but in the compiled version the file is “relax.default.linixgccrelease”.

moreover, the relax protocol is very well running in the binary version, however, in the compiled version it is giving errors (/home/gnss/singhma/rosetta/software/ros-c/main/source/bin/relax.default.linuxgccrelease: error while loading shared libraries: libcppdb.so: cannot open shared object file: No such file or directory).

 

what could be the reason for this?

 

Malkeet

[Anonymous]

thank you, I will try with updated version of gcc.

malkeet

[Anonymous]

thank you, I will try with updated version of gcc.

malkeet

[Anonymous]

thank you, I will try with updated version of gcc.

malkeet

[Anonymous]

Hello!

I tried compiling rosetta 3.8 with gcc 6.2, but still it is ending up with errors (file atached herwith).

Many thanks in advance!

Malkeet

[Anonymous]

Hello!

I tried compiling rosetta 3.8 with gcc 6.2, but still it is ending up with errors (file atached herwith).

Many thanks in advance!

Malkeet

[Anonymous]

Hello!

I tried compiling rosetta 3.8 with gcc 6.2, but still it is ending up with errors (file atached herwith).

Many thanks in advance!

Malkeet

[Anonymous]

Hello!

 

the version command returns: 

[singhma@genesis ~]$ scl enable devtoolset-6 bash

[singhma@genesis ~]$ gcc --version

gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-3)

 

and the which command : /usr/bin/g++

 

Thanks!

Malkeet

[Anonymous]

Hello!

 

the version command returns: 

[singhma@genesis ~]$ scl enable devtoolset-6 bash

[singhma@genesis ~]$ gcc --version

gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-3)

 

and the which command : /usr/bin/g++

 

Thanks!

Malkeet

[Anonymous]

Hello!

 

the version command returns: 

[singhma@genesis ~]$ scl enable devtoolset-6 bash

[singhma@genesis ~]$ gcc --version

gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-3)

 

and the which command : /usr/bin/g++

 

Thanks!

Malkeet

[Anonymous]

There is a compiler compatibility script at the top of the documentation page I linked earlier – what does it return?

Have you made modifications to the settings files in tools/build?  Modifications to tools/build/user.settings are common to resolve pathing issues – I’m wondering if it’s overriding your path in such a way that you still get g++ 4 from scons even though you have a more recent one installed in your normal environment.  The prepended “scl enable …” makes me especially suspicious of that type of problem.

[Anonymous]

There is a compiler compatibility script at the top of the documentation page I linked earlier – what does it return?

Have you made modifications to the settings files in tools/build?  Modifications to tools/build/user.settings are common to resolve pathing issues – I’m wondering if it’s overriding your path in such a way that you still get g++ 4 from scons even though you have a more recent one installed in your normal environment.  The prepended “scl enable …” makes me especially suspicious of that type of problem.

[Anonymous]

There is a compiler compatibility script at the top of the documentation page I linked earlier – what does it return?

Have you made modifications to the settings files in tools/build?  Modifications to tools/build/user.settings are common to resolve pathing issues – I’m wondering if it’s overriding your path in such a way that you still get g++ 4 from scons even though you have a more recent one installed in your normal environment.  The prepended “scl enable …” makes me especially suspicious of that type of problem.

[Anonymous]

Hello !

Thanks for your response. I tried the compiler command and it passed all tests (file attached)

I didn’t make any change to tools/build/user.settings file.  Could you please tell what to do in this file ? 

 

Thanks in advance!

malkeet

[Anonymous]

Hello !

Thanks for your response. I tried the compiler command and it passed all tests (file attached)

I didn’t make any change to tools/build/user.settings file.  Could you please tell what to do in this file ? 

 

Thanks in advance!

malkeet

[Anonymous]

Hello !

Thanks for your response. I tried the compiler command and it passed all tests (file attached)

I didn’t make any change to tools/build/user.settings file.  Could you please tell what to do in this file ? 

 

Thanks in advance!

malkeet

[Anonymous]

If `g++ –version` is giving you the correct version at the commandline, but scons doesn’t seem to be picking things up, I’d first recommend copying  main/source/tools/build/site.settings.killdevil to main/source/tools/build/site.settings  

By default Scons will bypass your shell’s PATH settings. The site.settings.killdevil has facilities for enabling your path settings in the scons build process.

[Anonymous]

If `g++ –version` is giving you the correct version at the commandline, but scons doesn’t seem to be picking things up, I’d first recommend copying  main/source/tools/build/site.settings.killdevil to main/source/tools/build/site.settings  

By default Scons will bypass your shell’s PATH settings. The site.settings.killdevil has facilities for enabling your path settings in the scons build process.

[Anonymous]

If `g++ –version` is giving you the correct version at the commandline, but scons doesn’t seem to be picking things up, I’d first recommend copying  main/source/tools/build/site.settings.killdevil to main/source/tools/build/site.settings  

By default Scons will bypass your shell’s PATH settings. The site.settings.killdevil has facilities for enabling your path settings in the scons build process.

[Anonymous]

Hello!

is it /site.settings  file? because there is no such file. there are files ‘site.settings.xx’, where xx is wiggins, vaxmpi etc. 

Based on our earlier discussion, I copied the content of site.settings.killdevil to users.settings and tried to compile the source.  

[singhma@genesis source]$ ./scons.py -j8 mode=release bin

scons: Reading SConscript files …

Traceback (most recent call last):

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/SConstruct”, line 150, in main

    build = SConscript(“tools/build/setup.py”)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 614, in __call__

    return method(*args, **kw)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 551, in SConscript

    return _SConscript(self.fs, *files, **subst_kw)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 260, in _SConscript

    exec _file_ in call_stack[-1].globals

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 429, in <module>

    build = setup()

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 420, in setup

    build.settings = setup_build_settings(build.options)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 216, in setup_build_settings

    user = Settings.load(“user.settings”, “settings”)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/settings.py”, line 130, in load

    execfile(file, settings)

  File “user.settings”, line 29, in <module>

NameError: name ‘os’ is not defined

scons: done reading SConscript files.

scons: Building targets …

scons: `bin’ is up to date.

scons: done building targets.

 

this seems liek completed but i doubt there is some problem. 

– it took some seconds to complete.

– ‘bin’ folder is empty.

 

Thanks!

malkeet

 

[Anonymous]

Hello!

is it /site.settings  file? because there is no such file. there are files ‘site.settings.xx’, where xx is wiggins, vaxmpi etc. 

Based on our earlier discussion, I copied the content of site.settings.killdevil to users.settings and tried to compile the source.  

[singhma@genesis source]$ ./scons.py -j8 mode=release bin

scons: Reading SConscript files …

Traceback (most recent call last):

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/SConstruct”, line 150, in main

    build = SConscript(“tools/build/setup.py”)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 614, in __call__

    return method(*args, **kw)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 551, in SConscript

    return _SConscript(self.fs, *files, **subst_kw)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 260, in _SConscript

    exec _file_ in call_stack[-1].globals

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 429, in <module>

    build = setup()

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 420, in setup

    build.settings = setup_build_settings(build.options)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 216, in setup_build_settings

    user = Settings.load(“user.settings”, “settings”)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/settings.py”, line 130, in load

    execfile(file, settings)

  File “user.settings”, line 29, in <module>

NameError: name ‘os’ is not defined

scons: done reading SConscript files.

scons: Building targets …

scons: `bin’ is up to date.

scons: done building targets.

 

this seems liek completed but i doubt there is some problem. 

– it took some seconds to complete.

– ‘bin’ folder is empty.

 

Thanks!

malkeet

 

[Anonymous]

Hello!

is it /site.settings  file? because there is no such file. there are files ‘site.settings.xx’, where xx is wiggins, vaxmpi etc. 

Based on our earlier discussion, I copied the content of site.settings.killdevil to users.settings and tried to compile the source.  

[singhma@genesis source]$ ./scons.py -j8 mode=release bin

scons: Reading SConscript files …

Traceback (most recent call last):

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/SConstruct”, line 150, in main

    build = SConscript(“tools/build/setup.py”)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 614, in __call__

    return method(*args, **kw)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 551, in SConscript

    return _SConscript(self.fs, *files, **subst_kw)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/external/scons-local/scons-local-2.0.1/SCons/Script/SConscript.py”, line 260, in _SConscript

    exec _file_ in call_stack[-1].globals

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 429, in <module>

    build = setup()

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 420, in setup

    build.settings = setup_build_settings(build.options)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/setup.py”, line 216, in setup_build_settings

    user = Settings.load(“user.settings”, “settings”)

  File “/home/gnss/singhma/rosetta/software/rosetta_src_2017.08.59291_bundle/main/source/tools/build/settings.py”, line 130, in load

    execfile(file, settings)

  File “user.settings”, line 29, in <module>

NameError: name ‘os’ is not defined

scons: done reading SConscript files.

scons: Building targets …

scons: `bin’ is up to date.

scons: done building targets.

 

this seems liek completed but i doubt there is some problem. 

– it took some seconds to complete.

– ‘bin’ folder is empty.

 

Thanks!

malkeet

 

[Anonymous]

Right, the “site.settings” file doesn’t exist, so you copy the “site.settings.killdevil” file to that name, creating it.

You can also copy it to the “user.settings” file, though if you do that you may need to change the line which reads `”site” : {` to read `”user” : {` instead.

I’m a little surprised at the error message you’re getting, as the ‘os’ should be present due to the “import os” line in the site.settings.killdevil file.  Did you copy site.settings.killdevil exactly? (e.g. with something like `cp site.settings.killdevil  user.settings`?)  The only way I think you’d get that error is if something was messed up with the copy.

I’d recommend deleting your current `user.settings` file, and then doing a `cp site.settings.killdevil   site.settings` in the Rosetta/main/source/tools/build/ directory. That should fix things.

[Anonymous]

Right, the “site.settings” file doesn’t exist, so you copy the “site.settings.killdevil” file to that name, creating it.

You can also copy it to the “user.settings” file, though if you do that you may need to change the line which reads `”site” : {` to read `”user” : {` instead.

I’m a little surprised at the error message you’re getting, as the ‘os’ should be present due to the “import os” line in the site.settings.killdevil file.  Did you copy site.settings.killdevil exactly? (e.g. with something like `cp site.settings.killdevil  user.settings`?)  The only way I think you’d get that error is if something was messed up with the copy.

I’d recommend deleting your current `user.settings` file, and then doing a `cp site.settings.killdevil   site.settings` in the Rosetta/main/source/tools/build/ directory. That should fix things.

[Anonymous]

Right, the “site.settings” file doesn’t exist, so you copy the “site.settings.killdevil” file to that name, creating it.

You can also copy it to the “user.settings” file, though if you do that you may need to change the line which reads `”site” : {` to read `”user” : {` instead.

I’m a little surprised at the error message you’re getting, as the ‘os’ should be present due to the “import os” line in the site.settings.killdevil file.  Did you copy site.settings.killdevil exactly? (e.g. with something like `cp site.settings.killdevil  user.settings`?)  The only way I think you’d get that error is if something was messed up with the copy.

I’d recommend deleting your current `user.settings` file, and then doing a `cp site.settings.killdevil   site.settings` in the Rosetta/main/source/tools/build/ directory. That should fix things.

[Anonymous]

GPUs: nope.  We have (almost) no public support for GPU.  They optimize calculation in basically the opposite way Rosetta optimizes things, so it requires a lot of rewrite to use them efficiently.

 

multiple cores: We don’t support multithreading either.  We do support MPI, which will let you run multiple Rosetta calls together, sharing their output space (so that one run produces _0001, the next produces _0002, etc.  DDG does not support this, by the way – it runs multiple cycles internally and does not share the job distributor with most of Rosetta.  https://www.rosettacommons.org/docs/latest/rosetta_basics/MPI

[Anonymous]

“error while loading shared libraries: libcppdb.so: cannot open shared object file: No such file or directory”  

If you want background – Google around to learn about static versus dynamic linking.  The binaries we provide are statically linked, which means they are bigger but rely on no outside shared code.  The compiled binaries are dynamically linked, which means they’re much smaller but expect system libraries to be in place to rely on.  

The system libraries aren’t there because either A) the binary has been moved between the machines, they’ve been uninstalled, or most likely C) something has changed in your environment, so the paths are wrong.  If this is the thread I think it is (I can’t tell from the message compose page)  – you had to do some “setup” at commandline to make the compiler available in your path?  Probably Rosetta needs the same setup too to make sure the dynamic libraries are there on your path for runtime.

[Anonymous]

Regarding the setup for Rosetta to find the dynamic libraries, it’s specifically setting the LD_LIBRARY_PATH environment variable. (This isn’t a Rosetta-specific setting, but a system one.) You should be able to put it in your shell setup file (e.g. ~/.bashrc) and have it be present for all runs.

[Anonymous]

Dear rmoretti,

I am also in vain trying to install rosetta on mac OS high sierra 10.13.3 but I seem to be completly lost in space as a comet lander on this one. I am having a somewhat similar error ouput like malkeet and I was therefore hoping that the copying killdevil solution would solve the problems. However I end up having an output that ends like this with a raise KeyError. Do you have any ideas on what I need to do to solve this? Any help would be most appreciated! Thanks in advance! 

 

….. tools/build/setup.py”, line 210, in setup_build_settings

    site = Settings.load(“site.settings”, “settings”)

  File “/Users/karlmarkusroupe/rosetta_bin_mac_2017.08.59291_bundle/main/source/tools/build/settings.py”, line 130, in load

    execfile(file, settings)

  File “site.settings”, line 28, in <module>

  File “/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/UserDict.py”, line 23, in __getitem__

    raise KeyError(key)

KeyError: ‘LD_LIBRARY_PATH’

scons: done reading SConscript files.

scons: Building targets …

scons: `bin’ is up to date.

scons: done building targets.

 

[Anonymous]

If your system doesn’t have an LD_LIBRARY_PATH set, you can simply comment out the line that refers to it in your new site.settings file.

[Anonymous]

Dear rmoretti,

Sorry for the late reply and for having to bother you again. I had set up an email alert to go off when you answered but something must have gone amiss.

Anyway commenting out the LD_library path did the trick but I now ended up having  4 new error 1 errors. All of them seem to be focused on errors in the reference to the CDRSetOptionsParser. I am copy pasting the end part of it here below. Do you have any good avice on how to get past this new set back. Hope this is as easy a fix and thanks for your time! 

src/protocols/antibody/database/CDRSetOptionsParser.cc:104:31: error: reference

      to ‘core’ is ambiguous

        for ( core::Size i = 1; i <= core::Size(CDRNameEnum_proto_total)…

                                     ^

src/core/types.hh:28:11: note: candidate found by name lookup is ‘core’

namespace core {

          ^

/usr/local/include/boost/core/demangle.hpp:47:11: note: candidate found by name

      lookup is ‘boost::core’

namespace core

          ^

4 errors generated.

scons: *** [build/src/release/macos/17.4/64/x86/clang/9.0/default/protocols/antibody/database/CDRSetOptionsParser.os] Error 1

scons: building terminated because of errors.

[Anonymous]

The earlier site.settings changes make SCons MORE aware of what is on your system – it looks in more places to find the bits and peices it needs.

The error is because it is finding too many things – it is finding your system-installed boost and using that in place of the boost that comes with Rosetta.  That boost’s namespace core (not present in our boost, apparently) conflicts with ours.

The strongest solution is to tell SCons to ignore that boost install, but I don’t know how to do it.

You might be able to re-order the headers in that .cc file so that the boost headers – or, if the headers it includes themselves include boost, THOSE headers – are at the BOTTOM of the list.  The fact that the compiler says ambiguous makes me think it won’t help.  Removing a boost header would work, but if the header is otherwise necessary it will stop compiling…

[Anonymous]

This is actually due to a bug in the build system that already has a fix pending.  The issue is that the compiler is finding a system boost library, when Rosetta is expecting it to use the included Boost library — this results in the confusion. The fix is to fix the settings for compilation such that the included boost library is found before the system one.

In the Rosetta/main/source/tools/build/basic.settings file, go to line 1750 or so (In the “clang” block) and add four lines and modify two lines, such that it looks like the following:

 

     "clang" : {

"overrides" : {

"cc" : "clang",

"cxx" : "clang++",

},

"appends" : {

"flags" : {

# We don't use any C -- but if we did would it really be C99?

# Are there portability issues?

# (The "isystem" directives here are to tell clang not to print

# warnings found in these external headers.)

"cc" : [

"std=c99",

"isystem external/boost_1_55_0/",

"isystem external/",

"isystem external/include/",

"isystem external/dbio/",       # Added the comma

"isystem /usr/include",         # Added

"isystem /usr/local/include",   # Added

],

"cxx" : [

"std=c++11",

"isystem external/boost_1_55_0/",

"isystem external/",

"isystem external/include/",

"isystem external/dbio/",      # Added the comma

"isystem /usr/include",        # Added

"isystem /usr/local/include",  # Added

],

 

That should fix it on Macs, assuming you’re using the default Clang compiler (if you have things set up for GCC, you’ll need to do similar changes in the GCC block).

[Author]

Posts