- Boost-users - lists.boost.org

[Graph] Distributed edge insertion
by Sensei 25 Aug '15

25 Aug '15

Dear all, I am finding difficulties in understanding how distributed graphs work. My graph is simple, a string-valued property, with some edges, however, right now I have only one edge... if it works. Since each process will add its own nodes, is it possible to avoid communication when adding nodes, given that each node owns its own vertices, and no overlap is possible between processes? This would save some communication avoiding re-distribution of nodes. Can I add edges concurrently? Meaning, each process adds some edges. I've only seen examples with root adding edges, but that's limiting. My last question is maybe easy. I'm adding an edge that connects two nodes, owned by different processes. Doing this results in a crash. It seems I cannot access properties with operator[] when traversing processes. I'm posting the code below, along with the *crashing* output. I hope you can help getting a grasp on PBGL! Thanks! #include <iostream> #include <string> #include <vector> #include <cmath> #include <list> #include <functional> #include <boost/config.hpp> #include <boost/mpi.hpp> #include <boost/graph/use_mpi.hpp> #include <boost/graph/distributed/mpi_process_group.hpp> #include <boost/graph/distributed/adjacency_list.hpp> #include <boost/graph/iteration_macros.hpp> using namespace boost; using boost::graph::distributed::mpi_process_group; // Useless class class str { public: str(std::string s = std::string()) : s_(s) { // NOP } template<typename Archiver> void serialize(Archiver& ar, const unsigned int /*version*/) { ar & s_; } std::string s_; }; // Allow indexing and constructing namespace boost { namespace graph { // Index based on the str class template<> struct internal_vertex_name<str> { typedef multi_index::member<str, std::string, &str::s_> type; }; // Construct with str class template<> struct internal_vertex_constructor<str> { typedef vertex_from_name<str> type; }; } } // Handy typedef boost::adjacency_list<vecS, distributedS<mpi_process_group, vecS>, bidirectionalS, str> dgraph; typedef graph_traits<dgraph>::vertex_descriptor dvertex; // START ME UP int main(int argc, const char * argv[]) { boost::mpi::environment env; boost::mpi::communicator comm; std::cout << "RANK " << comm.rank() << std::endl; comm.barrier(); dgraph g; std::vector<dvertex> descriptors; // Each rank for(int i = 0; i < 10; i++) { str s(std::to_string(i + (comm.rank() + 1) * 100)); std::cout << "rank " << comm.rank() << " adding " << s.s_ << std::endl; descriptors.push_back( add_vertex(s, g) ); } BGL_FORALL_VERTICES(v, g, dgraph) { std::cout << "V @ " << comm.rank() << " " << g[v].s_ << " local " << v.local << " owner " << v.owner << std::endl; } std::cout << ">>> NUM VERTICES " << num_vertices(g) << " NUM EDGES " << num_edges(g) << std::endl; comm.barrier(); if(comm.rank() >= 0) { int from, dest; bool letsCrash = true; if (letsCrash) { from = 1; dest = 0; } else { from = 0; dest = 0; } std::cout << "rank " << comm.rank() << " adding edge owners " << descriptors[from].owner << " - " << descriptors[dest].owner << std::endl; add_edge(descriptors[from], descriptors[dest], g); } boost::synchronize(g); BGL_FORALL_EDGES(e, g, dgraph) { std::cout << "E @ " << comm.rank() << " " << g[boost::source(e, g)].s_ << " -> " << g[boost::target(e, g)].s_ << std::endl; } return 0; } RANK 0 RANK 1 rank 0 adding 100 rank 0 adding 101 rank 1 adding 200 rank 1 adding 201 rank 0 adding 102 rank 0 adding 103 rank 1 adding 202 rank 1 adding 203 rank 0 adding 104 rank 1 adding 204 rank 0 adding 105 rank 1 adding 205 rank 1 adding 206 rank 0 adding 106 rank 0 adding 107 rank 1 adding 207 rank 0 adding 108 rank 1 adding 208 rank 0 adding 109 rank 1 adding 209 V @ 0 100 local 0 owner 0 V @ 0 201 local 1 owner 0 V @ 0 102 local 2 owner 0 V @ 0 203 local 3 owner 0 V @ 0 104 local 4 owner 0 V @ 0 205 local 5 owner 0 V @ 1 200 local 0 owner 1 V @ 1 101 local 1 owner 1 V @ 1 202 local 2 owner 1 V @ 1 103 local 3 owner 1 V @ 1 204 local 4 owner 1 V @ 1 105 local 5 owner 1 V @ 1 206 local 6 owner 1 V @ 1 107 local 7 owner 1 V @ 1 208 local 8 owner 1 V @ 0 106 local 6 owner 0 V @ 0 207 local 7 owner 0 V @ 0 108 local 8 owner 0 V @ 0 209 local 9 owner 0 >>> NUM VERTICES 10 NUM EDGES 0 V @ 1 109 local 9 owner 1 >>> NUM VERTICES 10 NUM EDGES 0 rank 1 adding edge owners 0 - 1 rank 0 adding edge owners 1 - 0 Assertion failed: (v.owner == processor()), function operator[], file /usr/local/include/boost/graph/distributed/adjacency_list.hpp, line 1696. Assertion failed: (v.owner == processor()), function operator[], file /usr/local/include/boost/graph/distributed/adjacency_list.hpp, line 1696. E @ 0 201 -> E @ 1 101 -> [Senseis-MBP:40908] *** Process received signal *** [Senseis-MBP:40908] Signal: Abort trap: 6 (6)

1 1

boost::ptr_vector does not support const types
by Martin Gamwell Dawids 25 Aug '15

25 Aug '15

I would like to use a ptr_vector to hold a number of const values but it seems ptr_vector does not currently support the use of const value types. See this simple code example: #include "boost/ptr_container/ptr_vector.hpp" #include <vector> class X { const int i; public: X(int i) : i(i) {} int getI() const { return i; } }; int main() { boost::ptr_vector<X> bvx; boost::ptr_vector<const X> bvcx; std::vector<X*> svx; std::vector<const X*> svcx; bvx.push_back(new X(42)); bvcx.push_back(new X(42)); // does not compile svx.push_back(new X(42)); svcx.push_back(new X(42)); return 0; } I have tried this on MSVC 2005/8.0 and with g++ on Mac – i.e. Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn). On both compilers, calling 'push_back()' on a 'boost::ptr_vector<const X>' does not compile and on g++/Mac it yields this error message: ../boost/boost/ptr_container/ptr_sequence_adapter.hpp:249:37: error: reference to type 'const value_type' (aka 'void *const') could not bind to an lvalue of type 'value_type' (aka 'const X *') this->base().push_back( x ); // strong, commit ^ ptr_vector_test.cpp:22:8: note: in instantiation of member function 'boost::ptr_sequence_adapter<const X, std::__1::vector<void *, std::__1::allocator<void *> >, boost::heap_clone_allocator>::push_back' requested here bvcx.push_back(x); ^ /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/vector:697:62: note: passing argument to parameter '__x' here _LIBCPP_INLINE_VISIBILITY void push_back(const_reference __x); ^ 1 error generated. So the problem occurs when the passed value of type 'const X*' needs to be pushed to the backing 'std::vector<void*>' – i.e. a non-const 'void*' element type. The same problem exists for push_front(). A simple fix for 'push_back()' (and similar for 'push_front()') is to modify the file 'ptr_sequence_adapter.hpp' adding a cast of the value before pushing is: --- a/include/boost/ptr_container/ptr_sequence_adapter.hpp +++ b/include/boost/ptr_container/ptr_sequence_adapter.hpp @@ -246,7 +246,7 @@ namespace ptr_container_detail this->enforce_null_policy( x, "Null pointer in 'push_back()'" ); auto_type ptr( x ); // notrow - this->base().push_back( x ); // strong, commit + this->base().push_back( (void*) x ); // strong, commit ptr.release(); // nothrow } I am using a C-style cast as neither 'const_cast' nor 'reinterpret_cast' can be used here. (I know the formatting of the comments should also be fixed, but that would make my diff here more difficult to read.) Is there another workaround for this or have I overlooked something? /Martin

2 3

[multi-index] multi-index type trait
by Elizabeta 23 Aug '15

23 Aug '15

Hi how to test if the first index of boost::multi-index is key based or sequence based at compile time. I need to write something like this : template<class T,class M> void f(T& object,typename boost::enable_if<first_index_is_sequence<T>>::type* dummy = 0) { M element; object.push_back(element); } template<class T,class M> void f(T& object,typename boost::enable_if<first_index_is_key<T>>::type* dummy = 0) { M element; object.insert(element); } -- View this message in context: http://boost.2283326.n4.nabble.com/multi-index-multi-index-type-trait-tp467… Sent from the Boost - Users mailing list archive at Nabble.com.

2 5

Missing thread symbols when compiling from source: join(), ~thread() and start_thread()
by Edward Kornkven 22 Aug '15

22 Aug '15

Hello, I am trying to build Boost for linking with an application. I do not have admin access and there is an existing older Boost version in the system area. My problem is that there are three thread symbols that do not get defined by my build process: undefined reference to `boost::thread::join()' undefined reference to `boost::thread::~thread()' undefined reference to `boost::thread::start_thread()' Google reveals that this problem has been around for a while but the usual remedy is to install some binary or other. I need to build from source but for the life of me I can't understand what I am doing wrong that these symbols are not being defined. I can search everything that is being built using "nm" and they just aren't there. I think I am using a pretty standard build process of first building Boost.Build, then the rest: ./bootstrap.sh --with-toolset=gcc ./b2 install --prefix=${PREFIX} ${PREFIX}/bin/b2 --prefix=${PREFIX} toolset=gcc install I have geared down to various forms of magic: stage and then install, --without-thread followed by --with-thread, but I must be missing something basic about these libraries which I do not have occasion to use routinely. The build scripts are a bit opaque but don't indicate any errors. I am a little surprised that this isn't in an FAQ somewhere but maybe not many of us build Boost from source. Thanks for any assistance. Ed

1 0

build boost with specific msvcrt.lib
by Abhay Mhatre 22 Aug '15

22 Aug '15

is it possible to provide specific msvcrt.lib while building boost. It uses default one and my build system uses the one specified in build system. this causes heap corruption at the end of program termination. thanks

5 8

Building Boost 1.59.0 on Solaris 11 with Solaris Studio 12.4
by Leo Carreon 21 Aug '15

21 Aug '15

Hi Boosters, I have been attempting to build Boost 1.59.0 on Solaris 11 using Solaris Studio 12.4 in C++11 mode. So far, I have managed to locate on the web solutions to 3 issues. Now I’m down to 22 targets failing to build. Has anyone else attempted to do the same? I would appreciate it if you could share some of your fixes if you have any. Has anyone reported that they have been able to cleanly build in this environment? Kind regards, Leo

2 7

Regarding dijkstra_shortest_path() in boost graph library
by Rohith Reddy 21 Aug '15

21 Aug '15

Hello there, I started using Boost graph library recently for one of my projects.I was trying to implement dijkstra's shortest path algorithm with the help of the following function, dijkstra_shortest_paths (G, vertex(a, G), distance_map(make_iterator_property_map(distance.begin(), vertex_id, distance[0])). predecessor_map(make_iterator_property_map(parent.begin(), vertex_id, parent[0])). visitor(make_dijkstra_visitor(copy_graph(G_copy, on_examine_edge())))); But while comparing the definition of the function as in http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/dijkstra_shortest_paths…, to the above written function,it doesnt make sense, especially the third argument of the above written function.Can anyone help me with this? Thanks in advance.

1 0

Encoding with read_xml()
by ashish g 21 Aug '15

21 Aug '15

Hi I was looking into using the function 'read_xml()' which parses an xml file and populates a ptree. However I had a couple of questions which I couldnt find documentation for. 1. Is the encoding of the xml file format preserverd when the data is stored into the ptree. i.e lets say I have an xml file in utf-8 format. Are the strings inside my ptree utf-8 encoded as well? Or is it converted to system default encoding? 2. Passing the locale information as an argument to read_xml(), what effect does it have? I believe it assumes the xml file is formatted using the locale encoding, or uses system locale encoding if no arg is passed. Is this true even if my xml 's first line explicitly states that it uses and encoding diff from the system encoding. for eg: lets say im on windows with 1252 encoding. My xml file is utf-8, and is specified on the first line. If i call read_xml() on this file, without passing a locale as arg, does it use system 1252 encoding to parse the file or utf-8? Any pointers would be very helpful. Thank you -- *Ashish Gudla*

1 0

[MSM] Stack blown with deferred events (1.59.0)
by Tom Gibson 20 Aug '15

20 Aug '15

Hi Boost-Users and Christophe, I'm having an issue when using MSM's deferred events feature. I've written a very basic example of a state machine, simulating batching upon receipt of events using the deferred message queue as a buffer, and then handling the events in another state once a watermark has been hit. This however, is not working as well as I'd hoped. I've made the batch size configurable with a constructor variable on the state machine, and am using guards in the transition table to do the checking. Whilst functionally this works, when I set a reasonably large batch size (10,000), the process cores. I've done a bit of digging in gdb, and it appears that the stack is being blown. `ulimit -s shows 8192` as my stack limit, raising this to 16384 with a 10k batch size works, although the performance is pretty bad. Raising the batch size to beyond the stack limit once again breaks MSM. I've attached my test program, and am compiling and running locally with: ``` clang++ -std=c++11 -o batcher -g batch_test.cpp ./batcher <batch size> [total events=100000] ``` To summarize, I've a few questions with my scenario. 1. Am I using the deferred events feature correctly? I believe I've followed the documentation, but it is entirely possible there's something I'm missing! 2. Is this a valid use case for the deferred events feature, or something that wouldn't be recommended? Handling of deferred events seems to be fine normally, but with a large number of events, the performance does seem to suffer significantly. For example, `time` shows a batch size of 10 taking 0.470s, with a batch size of 5000 taking 24.415s. This gap is closed significantly when built with with -02 due to inlining, but its still significant. 3. The stack blowing to me implies recursion when items are processed from the deferred events queue (rather than a linear iteration over the container (deque in my case)). I've tried to follow this in the MSM code, but it's heavy stuff. In this scenario, is it possible I would be better to implement my own queuing mechanism? Thanks, Tom

1 0

Errors and failed targets when building [filesystem]
by morbid code 20 Aug '15

20 Aug '15

Hi guys, I am extremely new at boost. I downloaded the latest version and I did the following: I am using windows7 64 bit and GCC 5.1. I opened command line, went to C:\boost\tools\build and ran the command: bootstrap gcc The output is: Bootstrapping the build engine execcmd.c: In function 'onintr': execcmd.c:120:5: warning: implicit declaration of function 'out_printf' [-Wimpli cit-function-declaration] out_printf( "...interrupted\n" ); ^ execnt.c: In function 'maxline': execnt.c:524:12: warning: type defaults to 'int' in declaration of 'result' [-Wi mplicit-int] static result; ^ make.c: In function 'make': make.c:132:13: warning: implicit declaration of function 'out_printf' [-Wimplici t-function-declaration] out_printf( "...found %d target%s...\n", counts->targets, ^ make.c: In function 'make0': make.c:735:13: warning: implicit declaration of function 'out_flush' [-Wimplicit -function-declaration] out_flush(); ^ modules/path.c: In function 'path_exists': modules/path.c:16:12: warning: implicit declaration of function 'file_query' [-W implicit-function-declaration] return file_query( list_front( lol_get( frame->args, 0 ) ) ) ? ^ Bootstrapping is done. To build, run: .\b2 --prefix=DIR install Then I ran: b2 --prefix=DIR toolset=gcc install According to the long output 322 targets have been updated. I put the path C:\boost\tools\build\DIR\bin to the environment variables. Lastly, I ran: b2 --build-dir=C:\boost-filesystem toolset=gcc --with-filesystem stage The output: ...found 8 targets... ...updating 5 targets... common.mkdir C:\boost-filesystem\boost common.mkdir C:\boost-filesystem\boost\architecture common.mkdir C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 common.mkdir C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\32. o libs\config\checks\architecture\32.cpp:9:36: error: size of array 'test' is negative int test[sizeof(void*) == 4? 1 : -1]; ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\32.o" "libs\config\checks\archi tecture\32.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\32.o... ...failed updating 1 target... ...updated 4 targets... Performing configuration checks - 32-bit : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\64. o ...updated 1 target... - 64-bit : yes ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\arm .o libs\config\checks\architecture\arm.cpp:13:2: error: #error "Not ARM" #error "Not ARM" ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\arm.o" "libs\config\checks\arch itecture\arm.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\arm.o... ...failed updating 1 target... - arm : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\mip s1.o libs\config\checks\architecture\mips1.cpp:10:2: error: #error "Not MIPS1" #error "Not MIPS1" ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\mips1.o" "libs\config\checks\ar chitecture\mips1.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\mips1.o... ...failed updating 1 target... - mips1 : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\pow er.o libs\config\checks\architecture\power.cpp:13:2: error: #error "Not PPC" #error "Not PPC" ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\power.o" "libs\config\checks\ar chitecture\power.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\power.o... ...failed updating 1 target... - power : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\spa rc.o libs\config\checks\architecture\sparc.cpp:10:2: error: #error "Not SPARC" #error "Not SPARC" ^ "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o "C:\boost-fil esystem\boost\architecture\gcc-mingw-5.1.0\debug\sparc.o" "libs\config\checks\ar chitecture\sparc.cpp" ...failed gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0 \debug\sparc.o... ...failed updating 1 target... - sparc : no ...found 2 targets... ...updating 1 target... gcc.compile.c++ C:\boost-filesystem\boost\architecture\gcc-mingw-5.1.0\debug\x86 .o ...updated 1 target... - x86 : yes ...found 3 targets... ...updating 3 targets... common.mkdir C:\boost-filesystem\boost\bin.v2 link.touch C:\boost-filesystem\boost\bin.v2\test-symlink-source link.mklink C:\boost-filesystem\boost\bin.v2\test-symlink symbolic link created for C:\boost-filesystem\boost\bin.v2\test-symlink <<===>> test-symlink-source ...updated 3 targets... - symlinks supported : yes ...found 1 target... ...updating 1 target... config-cache.write C:\boost-filesystem\boost\bin.v2\project-cache.jam ...updated 1 target... Component configuration: - atomic : not building - chrono : not building - container : not building - context : not building - coroutine : not building - coroutine2 : not building - date_time : not building - exception : not building - filesystem : building - graph : not building - graph_parallel : not building - iostreams : not building - locale : not building - log : not building - math : not building - mpi : not building - program_options : not building - python : not building - random : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - timer : not building - wave : not building ...patience... ...found 690 targets... ...updating 51 targets... common.mkdir stage common.mkdir stage\lib common.mkdir C:\boost-filesystem\boost\bin.v2\libs common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0 common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ debug common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ debug\link-static common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ debug\link-static\threading-multi gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1 .0\debug\link-static\threading-multi\error_code.o gcc.archive C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\d ebug\link-static\threading-multi\libboost_system-mgw51-mt-d-1_59.a common.copy stage\lib\libboost_system-mgw51-mt-d-1_59.a C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\debug\link-st atic\threading-multi\libboost_system-mgw51-mt-d-1_59.a 1 file(s) copied. common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0 common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\debug common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\debug\link-static common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\debug\link-static\threading-multi gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\codecvt_error_category.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\operations.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\path.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\path_traits.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\portability.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\unique_path.o libs\filesystem\src\unique_path.cpp:28:0: warning: ignoring #pragma comment [-W unknown-pragmas] # pragma comment(lib, "Advapi32.lib") ^ gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\utf8_codecvt_facet.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\debug\link-static\threading-multi\windows_file_codecvt.o gcc.archive C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5.1 .0\debug\link-static\threading-multi\libboost_filesystem-mgw51-mt-d-1_59.a common.copy stage\lib\libboost_filesystem-mgw51-mt-d-1_59.a C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5.1.0\debug\lin k-static\threading-multi\libboost_filesystem-mgw51-mt-d-1_59.a 1 file(s) copied. common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ release common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ release\link-static common.mkdir C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\ release\link-static\threading-multi gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1 .0\release\link-static\threading-multi\error_code.o In file included from libs\system\src\error_code.cpp:16:0: ./boost/system/error_code.hpp:221:36: warning: 'boost::system::posix_category' d efined but not used [-Wunused-variable] static const error_category & posix_category = generic_category(); ^ ./boost/system/error_code.hpp:222:36: warning: 'boost::system::errno_ecat' defin ed but not used [-Wunused-variable] static const error_category & errno_ecat = generic_category(); ^ ./boost/system/error_code.hpp:223:36: warning: 'boost::system::native_ecat' defi ned but not used [-Wunused-variable] static const error_category & native_ecat = system_category(); ^ gcc.archive C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\r elease\link-static\threading-multi\libboost_system-mgw51-mt-1_59.a common.copy stage\lib\libboost_system-mgw51-mt-1_59.a C:\boost-filesystem\boost\bin.v2\libs\system\build\gcc-mingw-5.1.0\release\link- static\threading-multi\libboost_system-mgw51-mt-1_59.a 1 file(s) copied. common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\release common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\release\link-static common.mkdir C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5. 1.0\release\link-static\threading-multi gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\codecvt_error_category.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\operations.o libs\filesystem\src\operations.cpp:688:26: warning: '{anonymous}::create_symboli c_link_api' defined but not used [-Wunused-variable] PtrCreateSymbolicLinkW create_symbolic_link_api = PtrCreateSymbolicLinkW( ^ gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\path.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\path_traits.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\portability.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\unique_path.o libs\filesystem\src\unique_path.cpp:28:0: warning: ignoring #pragma comment [-W unknown-pragmas] # pragma comment(lib, "Advapi32.lib") ^ gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\utf8_codecvt_facet.o gcc.compile.c++ C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw -5.1.0\release\link-static\threading-multi\windows_file_codecvt.o gcc.archive C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5.1 .0\release\link-static\threading-multi\libboost_filesystem-mgw51-mt-1_59.a common.copy stage\lib\libboost_filesystem-mgw51-mt-1_59.a C:\boost-filesystem\boost\bin.v2\libs\filesystem\build\gcc-mingw-5.1.0\release\l ink-static\threading-multi\libboost_filesystem-mgw51-mt-1_59.a 1 file(s) copied. ...updated 51 targets... So there are some warning while Bootstrapping the build engine, errors and failed targets when building the filesystem library. Should I be worried about them? What should I do?

1 0