October 2009 - Boost-users - lists.boost.org

[statechart] forward_event()
by Commander Pirx 14 Oct '09

14 Oct '09

Hi, I have a state [A] with three orthogonal substates [X,Y,Z]. The states [A] and [X] provide custom reactions for an event [E]. If processing event [E] the state machine calls first the custom reaction in [A]. This method returns with forward_event() ; After this the custom reaction in [A] is called again. And then custom reaction in [X] is called. This is a little cumbersome. Why is the custom reaction in [A] called twice? And why is the outermost state called first? It would be something easier to work vice versa. First the more "specialized" inner states could do there work and then the "generalized" outer states can do the everything else. Pirx!

3 14

problem with enable_if_c and gcc4
by Lewis Hyatt 13 Oct '09

13 Oct '09

Hello Everyone- The following code compiles fine with g++ 4.1.2 but does not compile with 4.4.1, I get an error message saying the prototype does not match any declared in the class. This happens both with Boost 1.40.0 and 1.33.1, on Debian (x86 64-bit). Does anyone know what's up with this, is there some workaround? Thanks very much. #include <boost/utility/enable_if.hpp> #include <boost/type_traits/is_base_of.hpp> #include <boost/type_traits/is_same.hpp> template<typename T> struct A { struct B {}; template<typename U> typename boost::enable_if_c< boost::is_base_of<B, U>::value && !boost::is_same<B,U>::value> ::type f(U&); }; template<typename T> template<typename U> typename boost::enable_if_c< boost::is_base_of<typename A<T>::B, U>::value && !boost::is_same<typename A<T>::B, U>::value> ::type A<T>::f(U&) {} int main() { } t.cpp:20: error: prototype for 'typename boost::enable_if_c<(boost::is_base_of::value && (! boost::is_same::value)), void>::type A<T>::f(U&)' does not match any in class 'A<T>' t.cpp:12: error: candidate is: template<class T> template<class U> typename boost::enable_if_c<(boost::is_base_of::value && (! boost::is_same::value)), void>::type A::f(U&) -Lewis

1 1

[boost][filesystem] re-assign a recursive_directory_iterator
by Sascha Ochsenknecht 13 Oct '09

13 Oct '09

Hi, should it be possible to re-assign a filesystem::recursive_directory_iterator? I tried something like the following (could strip out my code and build a small test case if needed but this would take some time): fs::path aPath = ...; // assign to some valid path const fs::recursive_directory_iterator initial(path); const fs::recursive_directory_iterator end(); fs::recursive_directory_iterator current(path); // now increment current and do something with it (traverse directories etc). // ... // Later I want to go back to initial position with: current = initial; // but this causes a crash later when traversing again, seems that the (current == end) check gives wrong results and I dereference invalid current // I tried also the following: current = fs::recursive_directory_iterator(path); // this doesn't crash but (current == end) seems to give also wrong results I don't want to create 'current' as a temporary, so constructing a new 'current' when needed. In my case it is a class member. Anyhow, I can implement a workaround for me. Is it a bug or is it not wanted to re-assign the iterator? If it is not wanted to re-assign, maybe the assignment operator should be disabled? Thanks in advance, Sascha

2 1

[log] Status & getting started?
by Allen Cronce 13 Oct '09

13 Oct '09

Hi all, Currently we're using the John Torjo boost log implementation. Nothing seems to be happening with that library, so I'm exploring moving to a different logging solution. The Andrey Semashev log candidate seems to have some steam behind it. It got reviewed in February, an "RC3" version was deposited in the vault in August, and it looks like there's recent activity in its svn repository. But it's hard to get a clear picture as to its status. Can someone (Andrey?) give me some idea as to where this library is in the acceptance process? Assuming that this library is moving forward, what's the best way to get started with it? One advantage of the Torjo library was that it was header only. Looks like the Semashev version requires building. I have some reluctant experience with building boost as a whole (because I seem to end up doing it once a year or so). But I have no experience with building individual pieces like this. We're still using boost 1.36. I can see a post from Boris Schaeling indicating that the log library from February seems to work with this version. That's good news. But we're moving to 1.40 shortly. Does it make sense to take the 1.40 sources, graft in the log candidate sources in the expected places, then turn a build of the whole shebang? If not, can someone provide pointers regarding building individual libraries? Thanks in advance for information regarding the logging library's status, and any suggestions getting started with it. Best, -- Allen Cronce

1 0

New library for RPC-calls using only boost and C++0x
by Siegfried Kettlitz 13 Oct '09

13 Oct '09

Hello boost users and developers, i'm currently writing a library for making remote procedure calls to C++ objects. The library is based on the variadic templates extension coming with C++0x (already present in GCC 4.3) in conjunction with the boost library (threads, serialization, asio). The aim is to have a library, that is easy to integrate and doesn't require additional tools. Writing it, so far, has thaught me a lot about C++, templates, variadic templates, threading, networking etc.. I post this message, because i think that this library is quite handy in situations, where a developer already uses boost libraries and wants to add some networking functionality to his/her project and the usage of variadic templates instead of additional tools is quite new. One example would be remote monitoring an application by adding a "std::string get_status()"-function to some object. Implemented as example is a chat-system with a server and clients interacting by remote calls. This example is tested with a x64-linux and win32 using the portable boost-text-serialization. Multiple clients can connect to the server via the TCP/IP-acceptor (and disconnect without crashing the system). Implemented is a console-client for text input and display and a morse client, that interacts via a digital output device (relais card), which is connected via a serial port. The serial port and the digital output driver are both also connected via the rpc-system and can be physically located on separate computers. At this point, i have the basic bits together and a working rpc-library, that needs to be cleaned, refined and extended to match the practical needs. This means, that some programs and libraries have to be written, which use the rpc-library and show its bugs and limitations. The downside of it is, that the interface of the rpc-library may change one more time until it can be considered stable. Therefore it would not be good to test it widely in libraries posing similar requirements, but to test it with a variety of possible applications and provide the implementations as examples and (regression-/unit-)tests. - One library for Measurement/Automation is already in development. - The chat-server/client exists. - A transaction based game server is under consideration. - Some distributed parallel computing application with dynamic joining/leaving of clients. Can you give me some more ideas of different applications, which are easy to implement but yet useful? What would you like to have implemented and accessible by an rpc-library? One speed measurement using local (shared memory) channels resulted in 20000 calls/s and 60000 messages/s on a 1.8GHz Opteron. Do you know how this compares to other implementations on similar hardware? The TCP/IP-channel implementation using ASIO resulted in only about 100 synchronous calls/second regardless of the payload and almost no CPU load, which suggests that ASIO somewhere "sleeps" on linux systems for a few milliseconds. This would be fixed in some future implementation. Using asynchronous calls (1000 open calls) again leads to about 10000 calls/s. I'll have a closer look on what can be merged with "channels" from the boost vault[1], but from the first look it seems that "channels" targets a much more general approach. After the first tries, i realized, that my implemention has to be very specific (e.g. templates only where necessary). So, the design approaches might be too different. After the refinement, cleanup, some testing and documenting, i'd like to publish the rpc-library (and libraries based on it) under GPL- or boost-license. Then you'll hear from me again. In future i'll probably work 2-8 hours per week on the library and use it in some projects, but there's plenty of work left to do in various regions. This will leave space for other developers who might want to use and modify it to fit their needs. Some of the harder parts that would need implementation are redundant parallel connections and advanced routing, authentication of nodes, signing of messages, encryption of payload, access restriction to objects. Please let me know if * you are interested in this library in some way * have comments * know very similar libraries or * are interested in serialization using variadic function templates. Regards, Siegfried Kettlitz --- A short introduction on the library: * "nodes" are the central parts. They contain a factory for objects, store objects and forward "messages" to objects or other nodes in the network and contain a "scheduler" for executing function calls. The nodes are connected by "channels", which forward messages between the two connected nodes. Currently there is a TCP/IPv4 implementation using ASIO and direct forwarding. * Nodes connected by channels form a network, create and monitor virtual connections between each other. The network map is used to route messages between connected nodes. * An object has to supply a template for a class name (only if it can be constructed by the factory) and a template for registering the callable functions (also for abstract base classes which can't be constructed). * A function call is executed asynchronously (wrapper for synchronous call exists). The call to node.call(...) returns a "link_caller"-object. The function to be executed itself can optionally have "link_callee" as the first argument (which is invisible for the caller). The "link_caller"/"link_callee" is used for synchronization (wait for call to begin/finish execution), message forwarding (push/pop strings at caller/callee) and transfer/extraction of the return value. * Objects of class hierarchies with abstract base classes are possible and handled transparently. * Objects can be constructed by the factory of a node or an existing (externally constructed) object can be registered by the node. * Objects don't necessarily need to know (be modified, inherit something etc.) that they are part of the RPC-system and some of their functions are called remotely. * Objects can be aware that they are constructed by the factory and can, on construction be informed about their identity and get a reference to the node to make remote calls themselves. * An object is identified by a "reference" consisting of the "node_id" and the "object_id". * Parameters are passed (serialized, deserialized) by value. All function parameters must have the possibility to be serialized. Modifying referenced parameters won't affect the parameter at the caller. Pointers obviously won't work between nodes not sharing the same memory-address-space. * Called functions can use "link_callee" to make remote calls themselves, regardless of the object. * Priorities are assigned to calls and affect message forwarding and scheduling. * Calls to objects can be transformed into a boost::function using node.bind(...). * If a called function throws, the exception is forwarded as rpc::exception or a more specialized exception class. The exception is thrown at the caller, when waiting for interaction with the callee (e.g. wait for return value). * Template functions as targets are possible when specifying the template parameters of the function pointer when registering the function. * There is no need to use macros at all, although macros could be used to simplify some things. ---------- // Example for creating and calling an object. // Create a service. boost::asio::io_service node_io_service; // Create a node. rpc::node node_s(node_io_service, config); // Register the builder in order to build the server object later. node_s.register_builder<devicelib::chat_server_impl>(); // Register the interface of the client to be able to make calls to it. node_s.register_interface<devicelib::chat_client>(); // Create the server object. rpc::reference cs( node_s.get_id(), node_s.allocate_object_template<devicelib::chat_server_impl>() ); // Store the server in name server. // rpc::reference( node_s.get_id(), rpc::oid_simple_object_name_server ) -> A reference to the object_name_server. // rpc::sched_default() -> Default scheduling parameters. // &rpc::simple_object_name_server::store, cs -> function to call. // cs, "chat_server_object" -> function parameters. node_s.wrap_call( rpc::reference( node_s.get_id(), rpc::oid_simple_object_name_server ), rpc::sched_default(), &rpc::simple_object_name_server::store, cs, "chat_server_object" ); ---------- // Example for abstract base class. namespace devicelib { class chat_server : public chat_types { public: virtual void receive( std::string xml_message ) = 0; virtual user_id_t connect_user( rpc::reference a_client, std::string xml_user_info ) = 0; virtual std::string query_user( user_id_t id ) = 0; virtual void disconnect_user( user_id_t user ) = 0; virtual void join_room( user_id_t user, room_id_t room ) = 0; virtual std::list<user_id_t> list_users( ) = 0; virtual std::list<room_id_t> list_rooms( ) = 0; }; } --------------- // Example for registering the interface of the server object. // The template is declared in namespace rpc, therefore we need to define it there. namespace rpc { // For the base object. template<> void register_proxy_functions<devicelib::chat_server>( function_call_proxy<devicelib::chat_server>& ar_proxy ) { // Register the functions of the abstract base object using unique strings. ar_proxy.register_interface( &devicelib::chat_server::connect_user, "&chat_server::connect_user" ); ar_proxy.register_interface( &devicelib::chat_server::query_user, "&chat_server::query_user" ); ar_proxy.register_interface( &devicelib::chat_server::disconnect_user, "&chat_server::disconnect_user" ); ar_proxy.register_interface( &devicelib::chat_server::join_room, "&chat_server::join_room" ); ar_proxy.register_interface( &devicelib::chat_server::list_users, "&chat_server::list_users" ); ar_proxy.register_interface( &devicelib::chat_server::list_rooms, "&chat_server::list_rooms" ); } // For each implementation. template<> void register_proxy_functions<devicelib::chat_server_impl>( function_call_proxy<devicelib::chat_server_impl>& ar_proxy ) { // Register the functions of the base object. register_proxy_functions<devicelib::chat_server>( (function_call_proxy<devicelib::chat_server>&) ar_proxy ); // Make the functions of this object available. ar_proxy.register_interface( &devicelib::chat_server_impl::connect_user, &devicelib::chat_server::connect_user ); ar_proxy.register_interface( &devicelib::chat_server_impl::disconnect_user, &devicelib::chat_server::disconnect_user ); ar_proxy.register_interface( &devicelib::chat_server_impl::join_room, &devicelib::chat_server::join_room ); ar_proxy.register_interface( &devicelib::chat_server_impl::list_users, &devicelib::chat_server::list_users ); ar_proxy.register_interface( &devicelib::chat_server_impl::list_rooms, &devicelib::chat_server::list_rooms ); } // The implementation can be built, the base object not. template<> std::string class_builder_name<devicelib::chat_server_impl>() { // Give it an unique name here. return "chat_server_impl"; } } ----------------- 1: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Distr…

8 12

[iterators] advance and distance with custom random-access iterators
by Sebastian Weber 13 Oct '09

13 Oct '09

Hi! Is there any progress in the bug #2539 ?? It seems that the patch published there which is against a rather antiquated boost version is the only solution to the problem of iterator_adaptor/facade constructs which are random_access-tagged in order to make use of true random access operations in distance/advance operations. This is critical in performance relevant code... So is there any progress in incorporating some fixes in the public trunk? I understand that the problem is a misconception of the stl there, but an official solution would be great here... Sebastian

1 0

[BGL] saving all-pair shortest paths
by Shyamendra Solanki 13 Oct '09

13 Oct '09

Hi, I understand that both the floyd-warshall and johnson algorithms populate the DistanceMatrix for shortest distances between any pair of vertices. Could you give some hint how to get the actual shortest paths? Thanks, Shyam

2 5

Multi Index with BOOST_AUTO question.
by Surya Kiran Gullapalli 13 Oct '09

13 Oct '09

Hello all,I'm a newbie to multi-index. I ran into a strange problem with VS2008. When using BOOST_AUTO with multi-index I'm getting compilation errors (C2248) . Please see the following code. *<snip>* * * #include <iostream> #include <string> using namespace std ; #include <boost/multi_index_container.hpp> #include <boost/multi_index/mem_fun.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/identity.hpp> #include <boost/multi_index/member.hpp> #include <boost/foreach.hpp> #include <boost/typeof/typeof.hpp> using namespace boost ; using namespace boost::multi_index ; class Test { friend bool operator< (const Test& p_lhs, const Test& p_rhs) { return p_lhs._i < p_rhs._i ; } friend ostream& operator << (ostream& os, const Test& p_test) { os << "Integer: " << p_test._i << "\tString: " << p_test._s ; return os ; } private: int _i ; string _s ; public: Test (int i, string s): _i(i), _s(s) { } string getString (void) const { return _s ; } } ; struct byNumber { } ; struct byString { } ; int main (void) { typedef multi_index_container <Test, indexed_by < ordered_unique<tag<byNumber>, identity <Test> > , ordered_non_unique < tag<byString>, BOOST_MULTI_INDEX_CONST_MEM_FUN(Test, string, getString) > > > Container ; typedef Container::index<byNumber>::type TestByNumber ; typedef Container::index<byString>::type TestByString ; Container c ; c.insert (Test(5, "Surya")) ; c.insert (Test(15, "Kiran")) ; //TestByNumber& tests = c.get<byNumber>() ; BOOST_AUTO(tests, c.get<byNumber>()) ; BOOST_FOREACH (Test t, tests) cout << t << endl ; return 0 ; } *</snip>* * * Compilation for this case fails with C2248. If I replace the BOOST_AUTO with the previous line's statement, compilation goes well. This happens with VS2008 only. with VS2005, there's no issue with BOOST_AUTO. Am I missing something here? Thanks, Surya

2 6

C# LINQ is cool. What about boost.qlang?
by Germán Diago 13 Oct '09

13 Oct '09

Hello. I've been reading a bit about C#'s linq and it's very cool in my opinion. I would like to see something similar in c++, and boost is the ideal place I think. As I would like to see something similar, I started a prototype adapted to c++. For now I've been playing with the basics: -from, where and select operators. -it just can be used (for now) with from, where and select, all in a row, but this will change. -it should work with any range: containers, boost.range, etc. -it's just a c++0x version. It works great with lambdas (gcc svn has lambdas). -Can use any boost.fusion sequence as the object type to query. (Although the plan is to be able to give data providers to use to query any type of source. The prototype works in the following way. For example (C++0x) : vector<int> numbers = {1, 2, 3, 4, 8, 5, 9 , 24, 19, 15, 12 } auto query = from(numbers).where([](int i) { return i < 15 && i > 10}). select(fields::full_object); This will construct an object with the query (without evaluating it). The original Range CANNOT be modified. If you want to modify , copy the result to a new container (in the future call query.to_vector(), query.to_list() to return a list or vector of objects. This will evaluate everything: for (auto it = query.begin(); it != query.end(); ++it) cout << *it << endl; You can traverse the range as many times as you like, and If you have, for example: struct Doctor { string name_; string surname_; string specializedin_; }; BOOST_FUSION_ADAPT_STRUCT(Doctor...) you can do, for example: vector<Doctor> doctors = {....}; auto query = from(doctors).where([](const Doctor & d) { return d.surname_ == "Smith"; }). select(fields::_1); The plan to improve readability is to use fusion associative sequence to do: auto query = from(doctors).where([](const Doctor & d) { return d.surname_ == "Smith"; }). select(Doctorfields::name, Doctorfields::specializedin); The query will return a tuple<string, string> in this case (the one before this would return tuple<string>. Queries with multiple fields don't work for now. A first implementation with the ability to select the full object or a field number (not several, but planned) is attached. Test it if you want and tell me what you think. The plan would be the same as the .NET platform: to be able to query XML, text files, objects, databases... giving extension points to add data providers. Another thing that doesn't work right now is to nest a query inside another query, but I'll work on it. Feedback is welcome.

2 2

Re: [Boost-users] 1.40 and pch - gcc problems?
by Vial, Florent 13 Oct '09

13 Oct '09

Hi everyone, I downloaded and built bjam-3.17 under linux x86_64 (RHEL 4.6). I then built boost 1.40.0 using following command line: ../boost-jam-3.1.17/bin.linuxx86_64/bjam --build-dir=/tmp/build-boost-1_40_0 stage --build-type=complete --layout=tagged My user-config.jam has just been modified so that the toolset used is gcc4.2.3. I got following warnings in the math library: gcc.compile.c++ /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/release/l ink-static/assoc_laguerrel.o libs/math/build/../src/tr1/assoc_laguerrel.cpp:6:21: warning: /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/release/l ink-static/../src/tr1/pch.hpp.gch: created and used with different settings of -fpic gcc.compile.c++ /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/release/l ink-static/assoc_legendrel.o libs/math/build/../src/tr1/assoc_legendrel.cpp:6:21: warning: /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/release/l ink-static/../src/tr1/pch.hpp.gch: created and used with different settings of -fpic gcc.compile.c++ /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/release/l ink-static/betal.o [snip lots of them] Then the serialization library reports following warnings: gcc.compile.c++ /tmp/build-boost-1_40_0/boost/bin.v2/libs/serialization/build/gcc-4.2.3/ release/link-static/xml_grammar.o In file included from ./boost/archive/impl/basic_xml_grammar.hpp:59, from libs/serialization/src/xml_grammar.cpp:16: ./boost/spirit/core/non_terminal/rule.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic_rule.hpp" In file included from libs/serialization/src/basic_xml_grammar.ipp:20, from libs/serialization/src/xml_grammar.cpp:63: ./boost/spirit/core/composite/operators.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic_operators.hpp" In file included from libs/serialization/src/basic_xml_grammar.ipp:21, from libs/serialization/src/xml_grammar.cpp:63: ./boost/spirit/core/composite/actions.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic_actions.hpp" In file included from libs/serialization/src/basic_xml_grammar.ipp:22, from libs/serialization/src/xml_grammar.cpp:63: ./boost/spirit/core/primitives/numerics.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic_numerics.hpp" gcc.compile.c++ /tmp/build-boost-1_40_0/boost/bin.v2/libs/serialization/build/gcc-4.2.3/ release/link-static/xml_iarchive.o In file included from ./boost/archive/impl/basic_xml_grammar.hpp:59, from ./boost/archive/impl/xml_iarchive_impl.ipp:41, from libs/serialization/src/xml_iarchive.cpp:32: ./boost/spirit/core/non_terminal/rule.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic_rule.hpp" However, the build seems to go through. Then i do following: ../boost-jam-3.1.17/bin.linuxx86_64/bjam --build-dir=/tmp/build-boost-1_40_0 --build-type=complete --layout=tagged stage I then get following messages for the math library: gcc.compile.c++ /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/debug/lin k-static/runtime-link-static/assoc_laguerre.o libs/math/build/../src/tr1/assoc_laguerre.cpp:6:21: warning: /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/debug/lin k-static/runtime-link-static/../src/tr1/pch.hpp.gch: not used because `_REENTRANT' not defined gcc.compile.c++ /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/debug/lin k-static/runtime-link-static/assoc_legendre.o libs/math/build/../src/tr1/assoc_legendre.cpp:6:21: warning: /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/debug/lin k-static/runtime-link-static/../src/tr1/pch.hpp.gch: not used because `_REENTRANT' not defined gcc.compile.c++ /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/debug/lin k-static/runtime-link-static/beta.o libs/math/build/../src/tr1/beta.cpp:6:21: warning: /tmp/build-boost-1_40_0/boost/bin.v2/libs/math/build/gcc-4.2.3/debug/lin k-static/runtime-link-static/../src/tr1/pch.hpp.gch: not used because `_REENTRANT' not defined [snip lots of them] I then type as root: ../boost-jam-3.1.17/bin.linuxx86_64/bjam install --prefix=/usr/local/boost1400-gcc423 And get following installation: [snip] common.copy /usr/local/boost1400-gcc423/lib/libboost_iostreams.a common.copy /usr/local/boost1400-gcc423/lib/libboost_math_tr1.a common.copy /usr/local/boost1400-gcc423/lib/libboost_math_tr1f.a common.copy /usr/local/boost1400-gcc423/lib/libboost_math_tr1l.a ...on 7500th target... common.copy /usr/local/boost1400-gcc423/lib/libboost_math_c99.a common.copy /usr/local/boost1400-gcc423/lib/libboost_math_c99f.a common.copy /usr/local/boost1400-gcc423/lib/libboost_math_c99l.a common.copy /usr/local/boost1400-gcc423/lib/libboost_program_options.a common.copy /usr/local/boost1400-gcc423/lib/libboost_python.a common.copy /usr/local/boost1400-gcc423/lib/libboost_serialization.a common.copy /usr/local/boost1400-gcc423/lib/libboost_wserialization.a common.copy /usr/local/boost1400-gcc423/lib/libboost_signals.a common.copy /usr/local/boost1400-gcc423/lib/libboost_prg_exec_monitor.a common.copy /usr/local/boost1400-gcc423/lib/libboost_unit_test_framework.a common.copy /usr/local/boost1400-gcc423/lib/libboost_thread.a common.copy /usr/local/boost1400-gcc423/lib/libboost_wave.a ...updated 7511 targets... However, for each library, i only have 2 files installed + 1 symbolic link: -rw-r--r-- 1 root root 148826 Oct 13 17:22 libboost_date_time.a lrwxrwxrwx 1 root root 28 Oct 13 17:22 libboost_date_time.so -> libboost_date_time.so.1.40.0 -rwxr-xr-x 1 root root 74552 Oct 13 17:22 libboost_date_time.so.1.40.0 Any idea what i might have done wrong ? (compiling under Win32/MSVC90 was no problem at all surprisingly) Thanks in advance, Florent ---------- Forwarded message ---------- From: "John Maddock" <j...(a)johnmaddock.co.uk> Date: 4 sep, 10:25 Subject: 1.40 and pch - gcc problems? To: BOOST Archives >I just got1.40and tried building. I kept having some pieces fail > with a complete build, sometimes I had gcc that ran until resources > exausted, sometimes the compiler would segfault. Eventaully I tracked > it down to the math library. After noticing the many errors from the > gch (things like : error _REENTERANT not defined or used diffrent > -fpic). I disabledpchfor the math library (actually the boost > project and the libs/math/test) and I did not have any more issues. Can you be more specific about the error messages? A: bjam --with-math will build just the math lib, if you could post the complete output that would be most helpful. There's something strange going on here though as it builds just fine locally here (ubuntu Linux), and on our regression test machines (various Linux flavours). Thanks, John. JOIN US FOR THE JOURNEY. View Our New Digital Cameras: www.arridigital.com Arnold & Richter Cine Technik GmbH & Co. Betriebs KG Sitz: Munchen - Registergericht: Amtsgericht Munchen - Handelsregisternummer: HRA 57918 Personlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH Sitz: Munchen - Registergericht: Amtsgericht Munchen - Handelsregisternummer: HRB 54477 Geschaftsfuhrer: Franz Kraus; Dr. Martin Prillmann

1 0