- Boost-users - lists.boost.org

Multiple link errors when using boost 1.44 boost::filesystem and gcc 4.1.2 on CentOS 5.5
by Potato Soup 29 Aug '10

29 Aug '10

I have installed gcc 4.1.2 (from Cent OS 5.5 repos), boost 1.44, and built all the libraries. I am able to link to all other libraries I try. As soon as I so much as add the include for boost::filesystem, and attempt to build my single .cpp file, I get the following errors: In function `__static_initialization_and_destruction_0(int, int)': testbuild.cpp:(.text+0xfa): undefined reference to `boost::system::generic_category()' testbuild.cpp:(.text+0x106): undefined reference to `boost::system::generic_category()' testbuild.cpp:(.text+0x112): undefined reference to `boost::system::system_category()' collect2: ld returned 1 exit status The linking stage fails and despite hours of googling I see no clear solution. I would be grateful for any advice on how to move past this, as it's the only thing holding me back from developing with boost. To be clear again, simply including <boost/filesystem.hpp> is enough to cause this when performing a link against libboost_filesystem.a.

2 1

boost serialize error
by Jack Bryan 29 Aug '10

29 Aug '10

Dear All: I am trying to use boost (1.43) serialize to transfer data. But I got errors: ---------------------------------------------------------------- path/boost_1_43_0/boost/config/stdlib/libstdcpp3.hpp:40:1: warning: "BOOST_HAS_THREADS" redefined<command line>:1:1: warning: this is the location of the previous definitionpath/boost_1_43_0/boost/serialization/access.hpp: In static member function âstatic void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = int*]â:path/boost_1_43_0/boost/serialization/serialization.hpp:74: instantiated from âvoid boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = int*]âpath/boost_1_43_0/boost/serialization/serialization.hpp:133: instantiated from âvoid boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = int*]âpath/boost_1_43_0/boost/archive/detail/iserializer.hpp:182: instantiated from âvoid boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::mpi::packed_iarchive, T = int*]â myProg.cpp:413: instantiated from herepath/boost_1_43_0/boost/serialization/access.hpp:118: error: request for member âserializeâ in âtâ, which is of non-class type âint*âpath/boost_1_43_0/boost/serialization/access.hpp: In static member function âstatic void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = double]â:path/boost_1_43_0/boost/serialization/serialization.hpp:74: instantiated from âvoid boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = double]âpath/boost_1_43_0/boost/serialization/serialization.hpp:133: instantiated from âvoid boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = double]âpath/boost_1_43_0/boost/archive/detail/iserializer.hpp:182: instantiated from âvoid boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::mpi::packed_iarchive, T = double]â myProg.cpp:413: instantiated from herepath/boost_1_43_0/boost/serialization/access.hpp:118: error: request for member âserializeâ in âtâ, which is of non-class type âdoubleâpath/boost_1_43_0/boost/serialization/access.hpp: In static member function âstatic void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = int*]â:path/boost_1_43_0/boost/serialization/serialization.hpp:74: instantiated from âvoid boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = int*]âpath/boost_1_43_0/boost/serialization/serialization.hpp:133: instantiated from âvoid boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = int*]âpath/boost_1_43_0/boost/archive/detail/oserializer.hpp:148: instantiated from âvoid boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::mpi::packed_oarchive, T = int*]â ---------------------------------------------------------------- It does not indicate the line number of my program with errors. The 413 is the last line of myProg.cpp. What is the meaning of "request for member serialize in t, which is of non-class type double" ? Any help is appreciated. Jack Aug. 28 2010

1 0

Fwd: Bundled properties for GraphProperties
by Saeed Nari 29 Aug '10

29 Aug '10

Hi all, I wonder if I can use a user defined class (bundled property) as a GraphProperty. The documentation just says about vertex and edge properties. Actually I could compile the below line with no errors: typedef adjacency_list<listS, vecS, directedS, vClass, eClass, gClass> Graph; vClass, eClass and gClass are my own classes. I don't know how to access the members from gClass anyway. Graph g; Vertex v; Edge e; g[v].vMember and g[e].eMember work fine. But I get error for g.gMember. Thanks Saeed

4 3

Is Boost-CMake Dead or Alive?
by Michael Jackson 28 Aug '10

28 Aug '10

http://ryppl.org/news/ So the boost-svn tracking is now hosted at Github. Ok. If you read farther down the page then it looks like Boost-CMake really _is_ going to be resurrected in the future? Is there any current activity with respect to Boost and git and cmake? I am so confused. I was going to take over for Troy S. in getting Boost-CMake ready after each release but if there is "Official" work doing this then I am not going to waste me time. Clarifications would be wonderful at this point. Thanks Mike Jackson

5 5

Any class for a buffer or temporary file ?
by Timothy Madden 28 Aug '10

28 Aug '10

Hello Is there a class or stream class in boost to implement a buffer that will use memory storage fro small data sizes, and disk storage in temporary files for large data sizes ? Or is there a (random-access) file stream class to open some unnamed or temporary file that will automatically be deleted after closing ? Thank you, Timothy Madden

1 0

[filesystem] Using filesystem library from Boost version 1.44 on Cygwin 1.7
by Clarke, Carus V 27 Aug '10

27 Aug '10

I have been using the filesystem library from Boost version 1.43 on a Cygwin 1.7.6-1 platform without any problems. The library was built using the Cygwin version of GCC 4.3.4. The library from the 1.44 version of Boost compiles compiles o.k., but the functions that access files no longer work. This appears to be true for both versions 2 and 3 of the library. Below is a simple program that runs o.k. with the Boost version 1.43 version of the library. The program runs but can not read the file status using Boost version 1.44. This program also works fine when built using MSVC 9.0 and Boost version 1.44. Am I doing something wrong? Any help would be appreciated. Thanks, Carus V. (Bud) Clarke carus.v.clarke(a)boeing.com //-------------------- #include <fstream> #include <iostream> #include <string> #include <boost/version.hpp> #define BOOST_FILESYSTEM_NO_DEPRECATED # if !defined(BOOST_FILESYSTEM_VERSION) # define BOOST_FILESYSTEM_VERSION 3 // disabled: # define BOOST_FILESYSTEM_VERSION 2 # endif #include <boost/filesystem.hpp> #include <boost/system/error_code.hpp> int main() { namespace boost_fs = boost::filesystem; const std::string pathStr = "foo"; std::ofstream ostrm(pathStr.c_str()); if (ostrm) { ostrm << "abcde-12345" << std::endl; ostrm.close(); } boost_fs::path path(pathStr); boost::system::error_code ec; std::cout << std::boolalpha; std::cout << "Checking status of file " << pathStr << "..." << std::endl; boost_fs::file_status st = boost_fs::status(path, ec); std::cout << "Error code value: " << ec.value() << std::endl; std::cout << "Error code message: " << ec.message() << std::endl; return 0; } //-------------------- This program's output on my system is shown below. The file 'foo' is written by the program and does actually exist. For version 2: boost::filesystem library version is v2 Checking status of file foo... Error code value: 0 Error code message: The operation completed successfully Does file exist? false For version 3: boost::filesystem library version is v3 Checking status of file foo... Error code value: 2 Error code message: The system cannot find the file specified Does file exist? false //--------------------

2 1

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0