I'm trying to link my program (gcc) with boost 1.70 (Wave specifically) and getting linker errors ("undefined reference").
I'm compiling boost into a static library with the following command with an addition flag BOOST_WAVE_SUPPORT_THREADING=0 (since threads support not needed in my case).
./b2 -j 8 toolset=gcc-7.2.0 cxxstd=17 link=static threading=multi runtime-link=static address-model=32 variant=release --without-python --stagedir=./linux/release stage
Compilation passes (few warnings).
Now, I'm building another static library (which uses wave). Same compiler and std is c++17 as previously. This one also builds successfully.
Third part is the actual executable which is linked to the previous static library and then linked to boost wave (actually system, wave, filesystem and regex). Compilation is also with std=17 (same results with std=c++11 btw). The error occurs at the linking phase of boost giving the following errors:
MyParserImplementation.cpp:(.text._ZN5boost4wave4impl19pp_iterator_functorINS0_7contextIN9__gnu_cxx17__normal_iteratorIPcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEENS0_8cpplexer12lex_iteratorINSE_9lex_tokenINS0_4util13file_positionINSH_11flex_stringIcSA_SB_NSH_9CowStringINSH_22AllocatorStringStorageIcSB_EES6_EEEEEEEEEENS0_26iteration_context_policies19load_file_to_stringE28advanced_preprocessing_hooksNS0_9this_typeEEEE12pp_directiveEv[_ZN5boost4wave4impl19pp_iterator_functorINS0_7contextIN9__gnu_cxx17__normal_iteratorIPcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEENS0_8cpplexer12lex_iteratorINSE_9lex_tokenINS0_4util13file_positionINSH_11flex_stringIcSA_SB_NSH_9CowStringINSH_22AllocatorStringStorageIcSB_EES6_EEEEEEEEEENS0_26iteration_context_policies19load_file_to_stringE28advanced_preprocessing_hooksNS0_9this_typeEEEE12pp_directiveEv]+0x301): undefined reference to `boost::wave::grammars::cpp_grammar_gen<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > >, std::__cxx11::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> > >::parse_cpp_grammar(boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > > const&, boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > > > const&, boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > const&, bool&, boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >&, std::__cxx11::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >, char*> > > >, boost::default_user_allocator_new_delete, std::mutex, 32u, 0u> >&)'
collect2: error: ld returned 1 exit status
(partial output)
As mentioned before, I've tried the same with std=c++11 and also with gcc 7.3.0 which is officially tested by boost for this version (stated in their website) with the same results.
It's also worth mentioning that when building the debug version of the libraries and executable, everything works fine.
edit:
here is the linking command:
g++ -O3 -DNDEBUG -std=c++17 -I /path/to/static/lib/myparser -I /path/to/boost/1_70_0 -lstdc++ -o bin/my_release/exe \
-L /path/to/static/lib/myparser/release -lmyparser -L /path/to/boost/1_70_0/linux/release/lib \
-l boost_system \
-l boost_wave \
-l boost_filesystem \
-l boost_regex \
Any idea what could be wrong?
Just happened to see this randomly - I ran into a similar problem today. The issue is that BOOST_WAVE_SUPPORT_THREADING=0 indirectly causes the fast pool allocator to use an internal null_mutex instead of std::mutex. The fix is to ensure you build the executable with the same BOOST_WAVE_SUPPORT_THREADING=0 and it should expect the null_mutex version instead.
Related
I've been trying to get a c++ project to build using this makefile:
https://pastebin.com/vMEMwH4C
The structure of my project is like this:
For context, I'm using a library called Raylib and trying to run on a windows machine. This makefile was provided with a project template and worked just fine before I tried to modify it to run with C++ instead of C and tried to include my source directories for the project instead of including just the main.cpp file.
It compiles just fine, but the linking is where I keep running into issues.
Here's the output when I run the make file:
Executing task in folder VSCode: C:/raylib/w64devkit/bin/mingw32-make.exe RAYLIB_PATH=C:/raylib/raylib PROJECT_NAME=main OBJS=src/main.cpp BUILD_MODE=DEBUG
i686-w64-mingw32-g++ -o main src/main.cpp -Wall -std=c++17 -D_DEFAULT_SOURCE -Wno-missing-braces -g -O0 C:/raylib/raylib/src/raylib.rc.data -Wl,--subsystem,windows -I. -IC:/raylib/raylib/src -IC:/raylib/raylib/src/external -Ilib/ -Ilib/util -Ilib/systems -Ilib/core -Ilib/components -ID://boost_1_81_0 -L. -LC:/raylib/raylib/src -LC:/raylib/raylib/src -lraylib -lopengl32 -lgdi32 -lwinmm -DPLATFORM_DESKTOP
...
C:/raylib/w64devkit/bin/ld.exe: C:\Users\Josh\AppData\Local\Temp\cczAGA5y.o: in function `Z4initv':
D:\Documents\WindowsRaylib\VSCode/src/main.cpp:276: undefined reference to `LocationManager::moveToLocation(nlohmann::json_abi_v3_11_2::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long, unsigned long long, double, std::allocator, nlohmann::json_abi_v3_11_2::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, MapLocation&, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, MapLocation, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >
>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, MapLocation> > >&, entt::basic_registry<entt::entity, std::allocator<entt::entity> >&, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&)'
... (and a bunch more of messages like these)....
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:408: main] Error 1
I've been looking through many posts trying to figure out how to include the right subdirectories in the linking process, but nothing seems to work. I would really appreciate some help!
(one odd thing I noticed is that the object file mentioned in the error "C:\Users\Josh\AppData\Local\Temp\cczAGA5y.o" is in the AppData folder, not my actual project folder. I can't figure out why, though.)
I tried Doxygen, but it was a bit slow, and it generated a lot of irrelevant individual dot files, so I'm pursuing the clang way to generate a call graph.
This answer https://stackoverflow.com/a/5373814/414063 posted this command:
$ clang++ -S -emit-llvm main1.cpp -o - | opt -analyze -dot-callgraph
$ dot -Tpng -ocallgraph.png callgraph.dot
and then
$ clang++ -S -emit-llvm main1.cpp -o - |
opt -analyze -std-link-opts -dot-callgraph
$ cat callgraph.dot |
c++filt |
sed 's,>,\\>,g; s,-\\>,->,g; s,<,\\<,g' |
gawk '/external node/{id=$1} $1 != id' |
dot -Tpng -ocallgraph.png
I managed to get the .dot files and unmangle them with c++filt, but the symbols are made of a lot of "noise", example:
"{__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::deallocate(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*, unsigned long)}"
"{void std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >::destroy<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >(std::allocator<std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >*)}"
"{void __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::destroy<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >*)}"
How does doxygen manage to "simplify" those symbols? Is there anything else other than STLfilt?
How can I properly filter symbols that are not relevant to my code, like allocators, constructors for containers? What does this sed and gawk command attempt to do? I tried them but I could not really see what they did.
I managed to do it, but it was not really trivial, and clang doesn't really provide options to filter "noisy" symbols.
It is important to know that graphviz cannot magically optimize the layout of a graph, so it's better to generate one graph per object file.
Here is the python filter I came up with to remove a lot of the noise. There are various things that are not part of std::, like sfml or nlohmann (a heavy templated json library that will generate a lot of symbols). I did not use regex, as it was not really relevant. Those filters should vary a lot depending on your code, the library you use, and eventually what parts of the standard library you use, since "it's just templates all the way down".
def filtered(s):
return not (
s.startswith("& std::__get_helper")
or s.startswith("__cx")
or s.startswith("__gnu_cxx::")
or s.startswith("bool nlohmann::")
or s.startswith("bool std::")
or s.startswith("decltype")
or s.startswith("int* std::")
or s.startswith("int** std::")
or s.startswith("nlohmann::")
or s.startswith("sf::")
or s.startswith("std::")
or s.startswith("void __gnu_cxx::")
or s.startswith("void format<")
or s.startswith("void nlohmann::")
or s.startswith("void std::")
or 'std::remove_reference' in s
or 'nlohmann::' in s
or '__gnu_cxx::' in s
or 'std::__copy_move' in s
or 'std::__niter' in s
or 'std::__miter' in s
or 'std::__get_helper' in s
or 'std::__uninitialized' in s
or 'sf::operator' in s
or s == 'sf::Vector2<float>::Vector2()'
or s == 'sf::Vector2<float>::Vector2(float, float)'
or s == 'sf::Vector2<float>::Vector2<int>(sf::Vector2<int> const&)'
or s == 'sf::Vector2<int>::Vector2()'
or s == 'sf::Vector2<int>::Vector2(int, int)'
)
Second, I also removed symbols that were not called, and calls to node absent from the object file. Concretely, I just cross checked nodes and edges in the generated DOT file
# filtering symbols I don't want
nodes_filtered = [(name, label) for (name, label) in nodes if filtered(label)]
# using a set() for further cross checking
nodes_filt_ids = set([name for (name, label) in nodes_filtered])
# we only keep edges with symbols (source and destination) BOTH present in the list of nodes
edge_filtered = [(a,b) for (a,b) in edges if a in nodes_filt_ids and b in nodes_filt_ids]
# we then build a set() of all the nodes from the list of edges
nodes_from_filtered_edges = set(sum(edge_filtered, ()))
# we then REFILTER AGAIN from the list of filtered edges
nodes_refiltered = [(name, label) for (name, label)
in nodes_filtered if name in nodes_from_filtered_edges]
Third, I used a makefile to cascade steps.
object_file.ll: object_file.cpp 2dhelpers.h.gch
$(CC) -S -emit-llvm $< -o $# $(args) $(inclflags)
object_file.ll.callgraph.dot: object_file.ll
opt $< -std-link-opts -dot-callgraph
object_file.cxxfilt.dot: object_file.ll.callgraph.dot
cat $< | llvm-cxxfilt > $#
object_file.cleaned.dot: object_file.cxxfilt.dot
python3 dot-parse.py $^
object_file.final.svg: object_file.cleaned.dot
dot -Tsvg $^ -o $#
Important to note that llvm-cxxfilt unmangled symbols a bit better than c++filt, although it was not perfect in my case.
The DOT file written by opt is quite trivial to parse, but you can still use pydot, although I found it to be a little slow, which it will if you have a lot of symbols (I have 2500 symbols, 5000 calls, reduce to 116 and 151)
If you really want to "combine" multiple object files and use a single graph, you absolutely can, using llvm-link
# linking llvm IR with this magic
all_objects.ll: file1.ll file2.ll file3.ll file4.ll file5.ll
llvm-link -S $^ -o all_objects.ll
Just apply command #2 to #5 to the resulting .ll file
In my case the single big graph was not easy to read, as multiple edges would cross and form "rivers". Adding color did not help a lot.
I am using the boost libraries for a project, and I am running into issues with the regex library. I am re-installing the libraries because I have upgraded to osx 10.9 (mavericks).
I am getting 2 undefined references for :
boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >::maybe_assign(boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > const&)
and
boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)
I am installing the boost libraries from source, specifically because I do not want to be using macports or any outside package installer. The reason is that my program is used in the mathematics and scientific community, and I am trying to keep it so that it can easily compiled from source with the appropriate dependencies (i.e. linking to certain libraries like gmp and mpfr, and, at least for now, boost).
The undefined reference issue is occurring regardless of the compiler I've used. That is, I have installed gcc 4.7.3 with apple's default compiler from the command line developer's tools. So this occurs for both gcc4.7.3 AND the default g++ (apple's clang, version 4.2.1).
This is a parallel application, so I have two versions of mpich3 installed, both compiled with the above 2 compilers and installed and built in separate directories.
When I built boost, I edited the user-config.jam file and added the lines
using gcc : 4.7.3 : "abs\loc\here" ;
and
using mpi ;
Then I ran sudo ./bootstrap.sh ; sudo ./b2 ; sudo ./b2 install (with the sudo being necessary as the installation files are in a /usr/local subdir)
Anyway, the file that is using the boost libraries is called para_aux_funcs.hpp / para_aux_funcs.cpp, and I am compiling with (well, after a Makefile that produces this for me to make all .o files from the .cpp ones ):
/usr/local/mpich3-mac-default/bin/mpic++ -cxx=/usr/local/bin/g++ -I/Users/matthewniemerg/Research/Bertini/Current/BertiniSource_v1.4/include -I/usr/local/boost_1_50_0/include -I../include -Dtimingstep2 -DTIXML_USE_STL -Wall -O3 -funroll-loops -fexpensive-optimizations -fopenmp -c para_aux_funcs.cpp -L/usr/local/boost_1_50_0/lib -lboost_regex -lboost_system -lboost_filesystem -o para_aux_funcs.o
I've also done this with the other mpi installation with the appropriate -cxx flag passed to indicate which compiler was used for the mpi compilation. And, I've also switch the order of where the -L and -l flags go in the above command, but with the same results.
That is, the following command gives me the undefined references indicated above:
/usr/local/mpich3-mac-default/bin/mpic++ -cxx=/usr/local/bin/g++ -I/Users/matthewniemerg/Research/Bertini/Current/BertiniSource_v1.4/include -I/usr/local/boost_1_50_0/include -I../include -Dtimingstep2 -DTIXML_USE_STL -Wall -O3 funroll-loops -fexpensive-optimizations -fopenmp -o paramotopy paramotopy.o point.o datagatherer.o failed_paths.o menu_cases.o master.o slave.o step2readandwrite.o runinfo.o mtrand.o random.o step2_funcs.o step1_funcs.o timing.o tinyxmlerror.o tinyxml.o tinystr.o tinyxmlparser.o xml_preferences.o para_aux_funcs.o ../lib/libbertini_osx9.a -lm -lmpfr -lgmp -L/usr/local/boost_1_50_0/lib -lboost_regex -lboost_system -lboost_filesystem
This looks like a linking error, but I am linking the libraries (i.e. -l flag) and pointing to the appropriate directories for where the library is located (i.e. -L flag) and indicating where the appropriate header files are (i.e. -I flag).
Any thoughts / ideas?
I'm getting some "undefined reference" errors in ld and am at a loss as to what's causing them.
My makefile builds several executables using commands like this:
g++ -ogui_program1 -Lpath/to/MyLibs gui_program1.o -lMyUI -lMyBusinessLogic \
-lMyUtil -lboost_regex
g++ -ogui_program2 -Lpath/to/MyLibs gui_program2.o -lMyUI -lMyBusinessLogic \
-lMyUtil -lboost_regex
g++ -ocli_program1 -Lpath/to/MyLibs cli_program1.o -lMyUI -lMyBusinessLogic \
-lMyUtil -lboost_regex
g++ -ocli_program2 -Lpath/to/MyLibs cli_program2.o -lMyUI -lMyBusinessLogic \
-lMyUtil -lboost_regex
And so on. (Actually, there are quite a few more libraries than this, but this is the general idea.)
MyUI, MyBusinessLogic, and MyUtil are all dynamic libraries that I've already built. To make writing the makefile simpler, the same list of libraries is used for both GUI and command line programs, even though the command line programs don't need libMyUI.so.
One and only one of the command line programs is giving numerous errors about undefined references to Boost.Regex symbols when I try to link it, even though I'm linking -lboost_regex with every binary:
libMyBusinessLogic.so: undefined reference to `boost::re_detail::perl_matcher >, boost::regex_traits > >::construct_init(boost::basic_regex > > const&, boost::regex_constants::_match_flags)'
libMyBusinessLogic.so: undefined reference to `boost::cpp_regex_traits::toi(char const*&, char const*, int) const'
libMyBusinessLogic.so: undefined reference to `boost::re_detail::perl_matcher, std::allocator > >, std::allocator, std::allocator > > > >, boost::regex_traits > >::match()'
libMyBusinessLogic.so: undefined reference to `boost::re_detail::perl_matcher, std::allocator > >, std::allocator, std::allocator > > > >, boost::regex_traits > >::construct_init(boost::basic_regex > > const&, boost::regex_constants::_match_flags)'
libMyBusinessLogic.so: undefined reference to `boost::re_detail::perl_matcher, std::allocator > >, std::allocator, std::allocator > > > >, boost::regex_traits > >::find()'
libMyBusinessLogic.so: undefined reference to `boost::basic_regex > >::do_assign(char const*, char const*, unsigned int)'
libMyBusinessLogic.so: undefined reference to `boost::re_detail::perl_matcher >, boost::regex_traits > >::match()'
Linking all other programs works fine. If I remove -lMyUI from the one command-line program, then it works fine, even though MyUI doesn't show up anywhere in the error list.
Why isn't ld finding Boost.Regex symbols, when I've added -lboost_regex to the end of the command? Why does removing a seemingly unrelated library fix it? Why do other programs link without any problems?
I've figured out at least most of the answer. Due to some sloppiness in my makefile rules, libMyUI.so was linked against boost_regex, but libMyBusinessLogic.so wasn't. I'm guessing that, as a result, linking MyUI caused boost_regex to get pulled in prematurely, before the linker knew all of the symbols that MyBusinessLogic would need from it.
As long as I'm consistent - either all of My*.so link with boost_regex, or none of them do - everything works. I'm not sure which of these solutions is most preferred, but at least I have a fix.
I'm triing to link to boost 1.50 on Mountain Lion with Xcode V 4.4
I'm using gcc 4.7, so no Xcode stuff should be involved.
Every time I'm triing to link it gives me this:
/usr/local/bin/g++ -o bin/parse -Lbin `root-config --ldflags` build/Bcf.o build/Bmf.o build/Boc.o build/EasyBMP.o build/Fei4.o build/Options.o build/RxChannel.o build/TxChannel.o -lboost_program_options -lboost_system -lboost_filesystem -lboc `root-config --libs` build/parse.o
Undefined symbols for architecture x86_64:
"start", referenced from:
-u command line option
(maybe you meant: boost::property_tree::string_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::id_translator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::cstart() const, boost::progress_display::restart(unsigned long) , boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::definition<boost::spirit::classic::scanner<__gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, boost::spirit::classic::scanner_policies<boost::spirit::classic::skip_parser_iteration_policy<boost::spirit::classic::alternative<boost::spirit::classic::alternative<boost::spirit::classic::space_parser, boost::spirit::classic::confix_parser<boost::spirit::classic::strlit<char const*>, boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>, boost::spirit::classic::alternative<boost::spirit::classic::eol_parser, boost::spirit::classic::end_parser>, boost::spirit::classic::unary_parser_category, boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >, boost::spirit::classic::confix_parser<boost::spirit::classic::strlit<char const*>, boost::spirit::classic::kleene_star<boost::spirit::classic::anychar_parser>, boost::spirit::classic::strlit<char const*>, boost::spirit::classic::unary_parser_category, boost::spirit::classic::non_nested, boost::spirit::classic::is_lexeme> >, boost::spirit::classic::iteration_policy>, boost::spirit::classic::match_policy, boost::spirit::classic::action_policy> > >::start() const )
"boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)", referenced from:
boost::filesystem::exists(boost::filesystem::path const&) in Bcf.o
"boost::filesystem::detail::file_size(boost::filesystem::path const&,boost::system::error_code*)", referenced from:
boost::filesystem::file_size(boost::filesystem::path const&) in Bcf.o
ld: symbol(s) not found for architecture x86_64
Boost was build after the Update and it worked before
I tried building it using macports or homebrew, but this breaks everything...
Here is the recipe I used to build Boost on 10.8 (with the latest Xcode from the App Store) that definitely works:
Download http://sourceforge.net/projects/boost/files/boost/1.50.0/boost_1_50_0.tar.bz2/download
tar jxvf boost_1_50_0.tar.bz2 && cd "boost_1_50_0/"
./bootstrap.sh --prefix=/opt/boost-1.50
(as admin user) sudo ./b2 install
sudo ln -snf boost-1.50 /opt/boost