August 2008 - Boost-users - lists.preview.boost.org

linker errors on 1.36.0
by Olaf Peter 27 Aug '08

27 Aug '08

Hi, I build release 1.36.0 on linux using jam successfully. By using this, I've got linker errors: interpreter.cpp.o: In function `void boost::call_once<void (*)()>(boost::once_flag&, void (*)())': interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x16): undefined reference to `boost::detail::get_once_per_thread_epoch()' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x4f): undefined reference to `boost::detail::once_epoch_mutex' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x89): undefined reference to `boost::detail::once_epoch_mutex' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0xc1): undefined reference to `boost::detail::once_global_epoch' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0xc7): undefined reference to `boost::detail::once_global_epoch' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0xd2): undefined reference to `boost::detail::once_global_epoch' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0xd8): undefined reference to `boost::detail::once_global_epoch' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0xdd): undefined reference to `boost::detail::once_global_epoch' CMakeFiles/eda.dir/src/python/interpreter.cpp.o:interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0xe3): more undefined references to `boost::detail::once_global_epoch' follow CMakeFiles/eda.dir/src/python/interpreter.cpp.o: In function `void boost::call_once<void (*)()>(boost::once_flag&, void (*)())': interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0xf2): undefined reference to `boost::detail::once_epoch_cv' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x125): undefined reference to `boost::detail::once_epoch_cv' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x198): undefined reference to `boost::detail::once_epoch_mutex' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x19f): undefined reference to `boost::detail::once_epoch_cv' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x20e): undefined reference to `boost::detail::once_global_epoch' interpreter.cpp:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x214): undefined reference to `boost::detail::once_global_epoch' main.cpp.o: In function `main': main.cpp:(.text+0x312): undefined reference to `boost::program_options::options_description::m_default_line_length' main.cpp:(.text+0x3aa): undefined reference to `boost::program_options::options_description::m_default_line_length' main.cpp:(.text+0x478): undefined reference to `boost::program_options::options_description::m_default_line_length' main.cpp:(.text+0x4c6): undefined reference to `boost::program_options::options_description::m_default_line_length' main.cpp:(.text+0x55e): undefined reference to `boost::program_options::options_description::m_default_line_length' Any ideas what gone wrong? linker flags where: -rdynamic -L/usr/local/boost_1_36_0/lib ... -lboost_python -lboost_program_options -lboost_thread -Wl,-rpath,/usr/local/boost_1_36_0/lib:/usr/lib/python2.5/config Thanks, Olaf

2 4

Re: [Boost-users] [filesystem] Changes in Boost 1.36 not documented?
by anthony giardullo 27 Aug '08

27 Aug '08

On Tue, Aug 26, 2008 at 4:54 PM, anthony giardullo <anthonyj(a)gmail.com> wrote: > Scott McMurray wrote: >> On Fri, Aug 15, 2008 at 12:57, Scott Finley <sfinley_at_[hidden]> wrote: >>> bfs_test.cpp: In function 'int main()': >>> >>> bfs_test.cpp:13: error: 'class >>> boost::filesystem::basic_directory_entry<boost::filesystem::basic_path<std::basic_string<char, >>> std::char_traits<char>, std::allocator<char> >, >>> boost::filesystem::path_traits> >' has no member named 'leaf' >>> >>> My mistake, or did something change/break? >>> >> >> It looks like you now need >> itr->path().leaf() >> or >> boost::implicit_cast<bfs::path const &>(*itr).leaf() >> ( http://beta.boost.org/doc/libs/1_36_0/libs/filesystem/doc/reference.html#Cl… >> ) >> >> As I recall, this change was part of optimization efforts to make >> iterating faster by caching the file_status. >> >> Also, it was decided that some of the names for path decomposition >> functions were confusing, particularly branch and leaf, so they were >> changed. The new path decomposition table suggests that you should >> now be using filename() instead of leaf(): >> http://beta.boost.org/doc/libs/1_36_0/libs/filesystem/doc/reference.html#Pa… >> (But it's likely backwards-compatible, so you shouldn't need to.) > > Yes, that's the theory. But it looks like 1.36.0 inadvertently renamed > basic_directory_entry::leaf without providing backward compatibility. > > I'll try to post a hotfix for that. Since basic_directory_entry::leaf is > deprecated anyhow, my initial reaction is that it should have been left > alone. > > --Beman > I would also appreciate a hotfix for this as this change is breaking a project that I am hoping to release soon. Is there an alternative solution I can use that will work in both 1.36 and earlier versions? I tried both filename() and path().leaf, but these do not work in 1.33. Thanks, Anthony

2 1

[GIL] Does not pass test on mingw g++ 4.3
by John C. Femiani 26 Aug '08

26 Aug '08

I used a fresh version of GIL from SVN trunk, and when I say make all from within the boost/libs/gil folder I get a slew of errors including: image.cpp:302: instantiated from here c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/boost_concept_check.h:223: error: conversion from 'boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>' to non-scalar type 'std::forward_iterator_tag' requested I have some patches to GIL, but I can not seem to do regression testing since the unmodified version of GIL itself does not seem pass its tests. Am I doing something wrong? I looked at the Jamfile.v2 and it did not seem to add much to what the makefile was doing, but just in case I ran bjam from within the GIL folder and got the same results -- image.cpp filed to compile. I thought the error might involve the iterator library because of the error message I got, but Boost.Iterator seemed to pass all of its tests on my system. Also, the GIL makefile has a line 'CXX=/usr/local/gcc430/bin/g++', so it looks like this version of the compiler has been tested before... --John

1 0

(no subject)
by Timothy Barrett 26 Aug '08

26 Aug '08

I have been using the boost libraries for a number of years on non linux platforms. Recently began developing on redhat EL4 and am running into an issue not seen with my library on other OS platforms. I'm getting an exception in assign_to_own. I have read the previous note on this issue in the forum but do not believe the make file for my application or for the library application are the cause of the exception. Any pointers on how to track down and resolve this issue? Tim Barrett

2 4

using libbost_test_exec_monitor with Visual Studio 2008?
by Ákos Maróy 26 Aug '08

26 Aug '08

Hi, I'm having troulbe using libboost_text_exec_monitor with Visual Studio 2008. Basically a very simple test application, that initializes a test suite in an init_unit_test_suite() function fails to link on Visual Studio, when trying to link against both libboost_unit_test_framework-vc90-mt-gd-1_35.lib and libboost_test_exec_monitor-vc90-mt-gd-1_35.lib . I'm egetting an error of LNK2019 saying that int __cdecl test_main(int, char ** const) is an unresolved external symbol. The error, strangely enough, is reported from libboost_test_exec_monitor-vc90-mt-fd-1_35.lib(test_main.obj), being a reference from the function test_main_caller::operator(). The same code compiles & links fine using gcc on Linux, linking to the same libraries (of course without the -vc90-mt-fd-1_35 suffix). The code is simply: #include <boost/test/unit_test.hpp> using namespace boost::unit_test; void test() { BOOST_CHECK(true); } test_suite * init_unit_test_suite(int, char **) { test_suite *ts = BOOST_TEST_SUITE("Test"); ts->add(BOOST_TEST_CASE(&test)); framework::master_test_suite().add(ts); return 0; } Shall I add something to the above code? shouldn't the text_exec_monitor library contain test_main? Akos

2 2

std::find_if with bind and iequals to create predicate
by Peter Barker 26 Aug '08

26 Aug '08

Hello, I've a container of these objects: class Search { public: ... const std::string& getName() const {return name_;} }; I want to find a search in a case insensitive manner and this works: iter = std::find_if(searches.begin(),searches.end(), boost::bind(&boost::iequals<std::string,std::string>,boost::bind(&Search::getName,_1),searchName,std::locale())); However, I would've preferred to not have to specify the template parameters to iequals, and not have to specify the locale argument to iequals (it's optional). Is there a cleaner way to do this? Regards, Jim

1 0

std::is_tr1_tuple<T> - how?
by Markus Werle 26 Aug '08

26 Aug '08

Hi! While migrating from boost::tuple to std::tr1::tuple (pain!) I have to rewrite a lot of compile-time-magic code. Among other things I am in need of a type info template <typename T> struct is_tr1_tuple; Any implementation hint or proposal welcome. best regards, Markus

3 6

Problem with boost 1.36, vs2005 and serialization library -> linker problem
by Hansi 26 Aug '08

26 Aug '08

Hello, in my application I wrote the serialization like in the pimpl example. With boost 1.34.1 this has worked. But now I have a few strange linker errors. e.g Error 1413 error LNK2001: unresolved external symbol "protected: __thiscall boost::archive::detail::archive_pointer_oserializer<class boost::archive::detail::polymorphic_oarchive_route<class boost::archive::binary_oarchive_impl<class boost::archive::binary_oarchive,char,struct std::char_traits<char> > > >::archive_pointer_oserializer<class boost::archive::detail::polymorphic_oarchive_route<class boost::archive::binary_oarchive_impl<class boost::archive::binary_oarchive,char,struct std::char_traits<char> > > >(class boost::serialization::extended_type_info const &)" (??0?$archive_pointer_oserializer@V?$polymorphic_oarchive_route@V?$binary_oarchive_impl@Vbinary_oarchive@archive@boost@@DU?$char_traits@D@std@@@archive@boost@@@detail@archive@boost@@@detail@archive@boost@@$$FIAE@ABVextended_type_info@serialization@3@@Z) main.obj and Error 1414 error LNK2001: unresolved external symbol "protected: __thiscall boost::archive::detail::archive_pointer_iserializer<class boost::archive::polymorphic_binary_iarchive>::~archive_pointer_iserializer<class boost::archive::polymorphic_binary_iarchive>(void)" (??1?$archive_pointer_iserializer@Vpolymorphic_binary_iarchive@archive@boost@@@detail@archive@boost@@$$FIAE@XZ) main.obj The problem has something to do with BOOST_CLASS_EXPORT(A) function. If I don't include it there is not the problem with the linker error. In the cpp file I have at the moment the instantion template void A::serialize(boost::archive::polymorphic_iarchive & ar,const unsigned int file_version); template void A::serialize(boost::archive::polymorphic_oarchive & ar,const unsigned int file_version); and template void A::serialize(boost::archive::binary_iarchive & ar,const unsigned int file_version); template void A::serialize(boost::archive::binary_oarchive & ar,const unsigned int file_version); What I have to do to solve that? Best regards Hansjörg

3 3

Format local time in W3C format (YYYY-MM-DDThh:mm:ss.sTZD) without providing the time zone myself?
by Paul Bormans 26 Aug '08

26 Aug '08

I'm having trouble in formatting the local time in W3C format. The format is described at http://www.w3.org/TR/NOTE-datetime as follows: YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) My first attempt was to use a ptime as follows: boost::posix_time::ptime t(boost::posix_time::microsec_clock::local_time()); boost::posix_time::time_facet* output_facet = new boost::posix_time::time_facet(); ss.imbue(std::locale(std::locale::classic(), output_facet)); output_facet->format("%Y-%m-%dT%H:%M:%S%f%Q"); ss << t; But when using a ptime in combination with a time_facet, the time zone (%Q) is ignored (also mentioned in the documentation http://www.boost.org/doc/libs/1_34_1/doc/html/date_time/date_time_io.html) So i thought to switch to the local time library which gives me the following code: typedef boost::date_time::time_facet<boost::local_time::local_date_time, char> ldt_facet; ldt_facet* output_facet = new ldt_facet("%Y-%m-%dT%H:%M:%S%f%Q"); ss.imbue(std::locale(std::locale::classic(), output_facet)); boost::local_time::time_zone_ptr zone; <=========== boost::local_time::local_date_time ldt1(boost::posix_time::microsec_clock::local_time(), zone); ss << ldt1; Problem here is that i have to provide the timezone where the software is running, which (offcourse) i do not know and actually would like the boost library to do this for me ;) After searching the web and reading the unittests i have found some clue's how i could make it work by first getting the difference between localtime and universial time and then format the timezone part myself. This will be much trouble for something that (i believe) should be in the library already. So my question is: How can i format the local time in W3C format (without providing the time zone myself)? Environment info: - Windows XP - VC2005 - Boost 1_34_1 Thanks for any hints & tips, Paul _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

[program-options] Problem with paths that have spaces
by Allen Cronce 26 Aug '08

26 Aug '08

Hi all, I'm trying to use program-options to specify a filesystem path object under Boost 1.35.0. The following code works fine when the path specified on the command line has no spaces in it. But when it does have spaces, I get an error. --snip-- #include <iostream> #include <sstream> #include <boost/program_options.hpp> #include <boost/filesystem/path.hpp> namespace po = boost::program_options; namespace fs = boost::filesystem; using namespace std; int main (int argc, char * argv[]) { int result = 0; try { fs::path inPath; po::options_description desc("Allowed options"); desc.add_options() ("in,i", po::value<fs::path>(&inPath), "Input file or directory <pathname>") ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (0 ==vm.count("in")) { throw invalid_argument("What? No input path specifed!"); } cout << "Input path = \"" << inPath.file_string() << "\"\n"; } catch(const boost::filesystem::filesystem_error& e) { cerr << "\nFilessytem error: " << e.what() << endl; result = 3; } catch(const std::exception& e) { cerr << "\nException error: " << e.what() << endl; result = 2; } catch(...) { cerr << "\nError: Caught an unknown exception!" << endl; result = 1; } return result; } --snip-- If I call the above with the following parameters, it works: --in "my_file" Input path = "my_file" But if I call it with a path that has a space in it, I get an error: --in "my file" Exception error: in option 'in': invalid option value 'my file' I know that I can work around the problem by loading the path into an interim string first, then use the string to initialize a path object. But unless I'm missing something, I would have thought that iteroperability between boost.program-options and boost.filesystem should be more seamless. It seems very common to want to load options into path objects. Best, -- Allen Cronce

2 1